From martin at openjdk.java.net Mon Feb 1 00:26:52 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 1 Feb 2021 00:26:52 GMT Subject: RFR: 8259074: regex benchmarks and tests [v2] In-Reply-To: References: <6PsLwBq14fzr95q7JsFcpZzACniQ7cB6OZ6cZZqwN8M=.e4545830-0777-45e9-8a61-0b29b51c60d9@github.com> Message-ID: On Sun, 31 Jan 2021 08:18:28 GMT, Aleksey Shipilev wrote: >> Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision: >> >> address comments from @amalloy; introduce technically correct use of "numeral" > > test/micro/org/openjdk/bench/java/util/regex/Trim.java line 119: > >> 117: assert ! lookBehind_find(); >> 118: assert ! find_loop_two_matchers(); >> 119: assert ! find_loop_usePattern(); > > At a risk of muddling the profiles a bit, this can be rewritten as: > > if (!simple_find()) throw new IllegalStateException("simple_find is incorrect"); > ... Thanks Aleksey. But I was hoping for something more magical. We really want the checking of the result of the benchmark method to be co-located in the source code with the method, but with zero disturbance to the benchmark numbers. Is such magic possible? ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From github.com+652983+dasbrain at openjdk.java.net Mon Feb 1 08:12:52 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Mon, 1 Feb 2021 08:12:52 GMT Subject: Integrated: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 09:38:40 GMT, Johannes Kuhn wrote: > Simple fix - one line change: https://openjdk.github.io/cr/?repo=jdk&pr=2000&range=00#sdiff-0. > > Most of the changes come from an additional test that fails without this fix: > > Error: Unable to load main class somelib.test.TestMain in module somelib > java.lang.IllegalAccessError: superclass access check failed: class somelib.test.TestMain (in module somelib) cannot access class java.lang.Object (in module java.base) because module java.base does not export java.lang to module somelib > > As described in JDK-8259395. > You can view the output of the test without patch here: https://github.com/DasBrain/jdk/runs/1668078245 > > Thanks to @AlanBateman for pointing out the right fix. This pull request has now been integrated. Changeset: cf942081 Author: Johannes Kuhn Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/cf942081 Stats: 454 lines in 11 files changed: 453 ins; 0 del; 1 mod 8259395: Patching automatic module with additional packages re-creates module without "requires java.base" Reviewed-by: attila, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2000 From redestad at openjdk.java.net Mon Feb 1 08:32:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 1 Feb 2021 08:32:57 GMT Subject: RFR: 8260605: Various java.lang.invoke cleanups [v3] In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com> References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com> Message-ID: > - Remove unused code > - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc) > - Apply pattern matching to make some code more readable Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: More cleanup, reduce allocations in InvokerBytecodeGenerator ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2300/files - new: https://git.openjdk.java.net/jdk/pull/2300/files/68d3475a..aa88b6fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=01-02 Stats: 45 lines in 1 file changed: 19 ins; 6 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300 PR: https://git.openjdk.java.net/jdk/pull/2300 From sundar at openjdk.java.net Mon Feb 1 09:32:00 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 1 Feb 2021 09:32:00 GMT Subject: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues [v2] In-Reply-To: References: Message-ID: <69VG2pHXENcmbm8jrgBnSc7c5mkboGixGiMKNtaYePE=.43bcec75-2960-46b3-9dab-1a11576c3ced@github.com> > Fixed compilation issues with the test. Test compiles and runs fine locally. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: Removed CompressorPluginTest.java from ProblemList.txt ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2091/files - new: https://git.openjdk.java.net/jdk/pull/2091/files/dfa440cd..6856cc68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2091&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2091&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2091.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2091/head:pull/2091 PR: https://git.openjdk.java.net/jdk/pull/2091 From github.com+4146708+a74nh at openjdk.java.net Mon Feb 1 09:34:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Mon, 1 Feb 2021 09:34:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik wrote: >> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. > >> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. > > I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed. You need add macos arm64 to hsdis. Having it working is fairly essential for debugging. Inside src/utils/hsdis, After cloning binutils make; make demo; ./build/macosx-arm64/hsdis-demo Results in: Hello, world! ...And now for something completely different: Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform hsdis output options: I fixed it by changing the makefile to force the build flags: ARCH=aarch64 CFLAGS/aarch64 += -m64 Resulting in: Hello, world! ...And now for something completely different: Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual Decoding for CPU 'aarch64' main: 0x10012719c sub sp, sp, #0x60 0x1001271a0 stp x29, x30, [sp, #80] ...etc Putting the library in the right place then made disassembly in java work for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From redestad at openjdk.java.net Mon Feb 1 10:00:02 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 1 Feb 2021 10:00:02 GMT Subject: RFR: 8260605: Various java.lang.invoke cleanups [v4] In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com> References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com> Message-ID: <1gjeWjb-j-3CQq9cCgNw82cScyMdqXoSL7bWBgfrjEQ=.31e19c6b-56cf-45ae-b83d-0894c39c1d77@github.com> > - Remove unused code > - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc) > - Apply pattern matching to make some code more readable Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Missing .values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2300/files - new: https://git.openjdk.java.net/jdk/pull/2300/files/aa88b6fd..0e3768b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300 PR: https://git.openjdk.java.net/jdk/pull/2300 From redestad at openjdk.java.net Mon Feb 1 10:24:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 1 Feb 2021 10:24:41 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 21:32:27 GMT, Martin Buchholz wrote: >> 8259074: regex benchmarks and tests > > @amalloy - you are invited to comment on regex content > @cl4es @shipilev - you are invited to point out my jmh bad practices The assertion discussion aside, the micros look fine to me. With an eye towards reducing total run time I'd ask you to consider if all parameter combinations are useful or if we can get the same value after some pruning. ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From ihse at openjdk.java.net Mon Feb 1 11:14:59 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 11:14:59 GMT Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16 Message-ID: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. ------------- Commit messages: - 8258378: Final nroff manpage update for JDK 16 Changes: https://git.openjdk.java.net/jdk16/pull/142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258378 Stats: 238 lines in 27 files changed: 98 ins; 111 del; 29 mod Patch: https://git.openjdk.java.net/jdk16/pull/142.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/142/head:pull/142 PR: https://git.openjdk.java.net/jdk16/pull/142 From vkempik at openjdk.java.net Mon Feb 1 11:22:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 1 Feb 2021 11:22:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: Message-ID: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward wrote: > You need add macos arm64 to hsdis. Having it working is fairly essential for debugging. > > Inside src/utils/hsdis, After cloning binutils > > ``` > make; make demo; ./build/macosx-arm64/hsdis-demo > ``` > > Results in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual > hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform > hsdis output options: > ``` > > I fixed it by changing the makefile to force the build flags: > > ``` > ARCH=aarch64 > CFLAGS/aarch64 += -m64 > ``` > > Resulting in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual > Decoding for CPU 'aarch64' > main: > 0x10012719c sub sp, sp, #0x60 > 0x1001271a0 stp x29, x30, [sp, #80] > ...etc > ``` > > Putting the library in the right place then made disassembly in java work for me. Hello, hsdis is a separate out-of-tree project and is not part of this jep. support for looking for proper hsdis dylib library was added as part of this jep. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Mon Feb 1 11:31:39 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 11:31:39 GMT Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16 In-Reply-To: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> References: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> Message-ID: <5tUHUibzsob8JsEH0afe_M8_kr3cmNyKtN7cSZWGf5k=.90ade8f8-820d-4cce-9796-ffb99eabee96@github.com> On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote: > Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. These updates have been made automatically from the markdown source files (which unfortunately is still closed-only). ------------- PR: https://git.openjdk.java.net/jdk16/pull/142 From alanb at openjdk.java.net Mon Feb 1 11:44:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 1 Feb 2021 11:44:44 GMT Subject: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues [v2] In-Reply-To: <69VG2pHXENcmbm8jrgBnSc7c5mkboGixGiMKNtaYePE=.43bcec75-2960-46b3-9dab-1a11576c3ced@github.com> References: <69VG2pHXENcmbm8jrgBnSc7c5mkboGixGiMKNtaYePE=.43bcec75-2960-46b3-9dab-1a11576c3ced@github.com> Message-ID: On Mon, 1 Feb 2021 09:32:00 GMT, Athijegannathan Sundararajan wrote: >> Fixed compilation issues with the test. Test compiles and runs fine locally. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Removed CompressorPluginTest.java from ProblemList.txt Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2091 From ihse at openjdk.java.net Mon Feb 1 12:22:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 12:22:46 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk wrote: >> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 >> >> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. >> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. > > Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This whole change seems very messy to me. :-( I'm having a hard time even untangling the PR to understand what's going on. Are you creating two new directories, "applauncherlib" and "applauncherlibcommon"? First of all, for shared libraries, the norm is to have a "lib-" prefix, not a "-lib" suffix. Secondly, there is already a "common" directory, is that not enough? Changes requested by ihse (Reviewer). src/jdk.jpackage/share/native/common/app.cpp line 26: > 24: */ > 25: > 26: #include "kludge_c++11.h" The name arose my curiosity, so I had to check out the file. Now that we indeed do have C++11 in the JDK (indeed, C++14), this should perhaps be revisited? (Not as part of this PR, of course) make/modules/jdk.jpackage/Lib.gmk line 61: > 59: JPACKAGE_OUTPUT_DIR := $(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources > 60: JPACKAGE_CXXFLAGS_windows := -EHsc -DUNICODE -D_UNICODE > 61: JPACKAGE_CFLAGS_windows := -DUNICODE -D_UNICODE Why is this change modifying Windows? I thought it was supposed to be a linux-only fix..? make/modules/jdk.jpackage/Lib.gmk line 65: > 63: )) > 64: > 65: $(BUILD_JPACKAGE_APPLAUNCHEREXE): $(call FindLib, java.base, java) Why did you remove this dependency? make/modules/jdk.jpackage/Lib.gmk line 106: > 104: CFLAGS_linux := -Wno-format-nonliteral, \ > 105: LDFLAGS := $(LDFLAGS_JDKLIB) \ > 106: -Wl$(COMMA)--version-script=$(TOPDIR)/make/modules/$(MODULE)/applauncherlib.ld-version-script, \ We should really not be using linker scripts. I did not understand your comment in the linker script -- was it only needed to handle your personal build environment? If so, you need to fix your build environment instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From github.com+4146708+a74nh at openjdk.java.net Mon Feb 1 12:37:45 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Mon, 1 Feb 2021 12:37:45 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> Message-ID: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> On Mon, 1 Feb 2021 11:19:34 GMT, Vladimir Kempik wrote: > Hello, hsdis is a separate out-of-tree project and is not part of this jep. Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) >support for looking for proper hsdis dylib library was added as part of this jep. I'm a little confused. Are you planning on adding a new disassembler? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From sundar at openjdk.java.net Mon Feb 1 13:00:41 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 1 Feb 2021 13:00:41 GMT Subject: Integrated: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 05:19:44 GMT, Athijegannathan Sundararajan wrote: > Fixed compilation issues with the test. Test compiles and runs fine locally. This pull request has now been integrated. Changeset: c0cde7dc Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/c0cde7dc Stats: 17 lines in 2 files changed: 5 ins; 1 del; 11 mod 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2091 From ihse at openjdk.java.net Mon Feb 1 14:09:51 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 1 Feb 2021 14:09:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward wrote: > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > support for looking for proper hsdis dylib library was added as part of this jep. > > I'm a little confused. Are you planning on adding a new disassembler? @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From erikj at openjdk.java.net Mon Feb 1 14:12:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 14:12:47 GMT Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16 In-Reply-To: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> References: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> Message-ID: On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote: > Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/142 From info at j-kuhn.de Mon Feb 1 14:50:51 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Mon, 1 Feb 2021 15:50:51 +0100 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle Message-ID: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> While implementing a prototype for JDK-8242888 (Convert dynamic proxy to hidden classes) I came across the problem that hidden classes can't be mentioned in the constant pool, breaking the constructor for serialization. To remedy that problem, I used a MHConstructorAccessor which delegates the actual work to MethodHandles - not unlike what JDK-6824466 suggests. As there has been previous work in that area, (I am aware of at least 3 independently developed prototypes for that bug/enchantment) I would like to ask a few questions around it: 1) What are the challenges? From the bug I could infer, that it's cold start is slower than NativeMethodAccessor, but still faster than the generated (bytecode spinning) accessors. 2) Are there any roadblocks that prevent replacing the MethodAccessorGenerator with accessors that use MethodHandles? From my limited tests, it appears to work well enough. 3) Should I try to implement it? From my POV, replacing MethodAccessorGenerator with accessors that delegate to MethodHandles has a few benefits: * Support for hidden classes. (Currently fallback to native accessors) * Removal of MethodAccessorGenerator (which is old and clunky) - Johannes From forax at univ-mlv.fr Mon Feb 1 14:58:32 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 1 Feb 2021 15:58:32 +0100 (CET) Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> Message-ID: <1915323937.509806.1612191512611.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Johannes Kuhn" > ?: "core-libs-dev" > Envoy?: Lundi 1 F?vrier 2021 15:50:51 > Objet: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle > While implementing a prototype for JDK-8242888 (Convert dynamic proxy to > hidden classes) I came across the problem that hidden classes can't be > mentioned in the constant pool, breaking the constructor for serialization. > > To remedy that problem, I used a MHConstructorAccessor which delegates > the actual work to MethodHandles - not unlike what JDK-6824466 suggests. > > As there has been previous work in that area, (I am aware of at least 3 > independently developed prototypes for that bug/enchantment) I would > like to ask a few questions around it: > > > > 1) What are the challenges? > > From the bug I could infer, that it's cold start is slower than > NativeMethodAccessor, but still faster than the generated (bytecode > spinning) accessors. > > 2) Are there any roadblocks that prevent replacing the > MethodAccessorGenerator with accessors that use MethodHandles? > > From my limited tests, it appears to work well enough. > > 3) Should I try to implement it? > > > > From my POV, replacing MethodAccessorGenerator with accessors that > delegate to MethodHandles has a few benefits: > > * Support for hidden classes. (Currently fallback to native accessors) > * Removal of MethodAccessorGenerator (which is old and clunky) Hi Johannes, the native accessors doesn't play with loom (a C stack frame in the middle of the Java stack can not be moved) so it doesn't seem to be a good idea to rely on the native accessors for hidden classes. > > - Johannes R?mi From andy.herrick at oracle.com Mon Feb 1 15:02:01 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 1 Feb 2021 10:02:01 -0500 Subject: jpackage problem submitting to Apple Store In-Reply-To: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org> References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org> Message-ID: Sorry to take so long to get back to you - I read this a week ago and I postponed reply till I could investigate some of the many points here.? Now a week later I still haven't found the time to do that so I will at least reply to what I do know now : First question is what OS version are you using ? To submit to the mac app store, everything must be signed with special certificate "3rd Party Mac ..." certificate from apple. The "Developer ID Application" and "Developer ID Installer" certificates can only be used for Distributing outside of the mac app store, though you can still notarize such signed apps. I don't myself have a "3rd Party Mac ..." type certificate, but I have been able to sign and notarize test apps with jpackage using the Developer ID certs I do have.? This step is required to post app on web where it can be downloaded and run on other machines running MacOS Catalina or later.? I would suggest getting this to work first, as all you other should apply to this environment. The entitlements used come from OpenJDK in open/make/data/macosxsigning/default.plist, but the can be fully customized by using the custom resource mechanism: create directory "resources", add file ".entitlements", run jpackage with "--resource-dir resources" options. The problem running app with "./" has been filed and a fix is pending, but you can run the same app with full path or in the same dir with just "" instead of "./" I have not been able to reproduce any of the other problems you allude to below, but without a "3rd Party Mac ..." type cert I really don't know which further complaints from app store are meaningful. If you get a Mac Store cert, I did add code in JDK16 that if mac-signing-user-name starts with "3rd Party" then it will just use it as the full cert name instead of pre-pending "Developer ID Application: " or "Developer ID Installer: ". /Andy On 1/24/2021 9:28 AM, John Crowley wrote: > Hi All, > > Have been having a problem trying to use jpackage to sign an app and submit it to the Apple Store. > > Attached are the following: > ? the script which invokes jpackage. Note that the attached ??txt? files show the values for all of the variables. > ? the output of this script > ? the output of the script running with ?verbose > > To try to summarize all of the attached: > Trying to create a signed DiskOrganizer-x.y.z.pkg to upload to the Apple Store. > The problem is with mac-sign and the attempt to load to the Apple Store. Otherwise, have successfully created .app, .pkg, and .dmg versions and they all execute/install as expected on my Mac (except as noted directly below in (4)). > This attempt used the jpackage in JDK 16-ea, build 31. Had essentially the same results using JDK 15.0.1 > Not shown in the attached is that if you try to manually start by going to DiskOrganizer/Contents/MacOS and execute ./DiskOrganizer directly, it fails with ? Error opening "/Applications/DiskOrganizer.app/Contents/Contents/app/DiskOrganizer.cfg" file: No such file or directory ? Note the ../Contents/Contents/app? Can fix this after installation by putting in a symlink: ln -s . Contents within the Contents directory. > > The last step of the pkg1.sh script invokes xcrun altool ?validate-app to validate, comments on these specific errors: > jpackage generates the Info.plist - some errors from this follow. Tried to make a copy of Info.plist, fix it, and then copy back into the .app, but this then invalidates the signature from ?mac-sign. > Key LSApplicationCategoryType contains Unknown. Probably need a jpackage ?mac-category to allow the user to set this. > Installer package may not include install scripts. No idea where such scripts may be located. There are no scripts in the ./inputs directory. Maybe in the runtime created by jlink? > The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/MacOS/DiskOrganizer", "DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/runtime/Contents/Home/lib/jspawnhelper" Probably need an ?mac-entitlements option in order to add this, and any other app-specific entitlements, to the code signing step. > Ensure that it is signed with your "3rd Party Mac Developer Installer" certificate. Don?t understand this - have assumed that the default was to use the Developer ID Application and Developer ID Installer certs (which are in my keychain). Are the "3rd Party ?" certs also needed? > Error in keyPath [product-metadata.product-identifier] ? No idea where this resides. Do you know? > Error in keyPath [product-metadata.product-version ? Ditto > The lowest minimum system version [none] in the Product Definition Property List ? .. does not equal 10.9 (from the Info.plist). Any idea where this gets set on the Apple side? Is it supposed to be somewhere within the .pkg? Maybe need a ?mac-min-version keyword? > Cannot find executable file that matches the value of CFBundleExecutable in the nested bundle DiskOrganizer [DiskOrganizer-app.pkg/Payload/DiskOrganizer.app/Contents/app] property list file.) ? No idea what this means. The generated .pkg does in fact install OK on my machine, and /Applications/DiskOrganizer.app launches OK with a double-click. > For Apple Store you have a Version (CFBundleShortVersionString) which would be set by ?app-version and is the version visible to the user. But can also have a CFBundleVersion which is really the build number. This must be 3 numbers separated by periods and must change for each upload to the store. So would be good to be able to set ?app-version 1.0 and ?app-build 1.0.4 (or ?mac-build) to be able to set both values. Otherwise the end user will see things like 1.0.23 (it took 23 uploads to make it through the Apple Store process) - which will be confusing. > > Sorry for the length of this email, but have been messing around for well over a week with no success. Also tried using jpackage without the ?mac-sign, running 'codesign' directly, etc. Still have not found the magic wand to make this all work. > > Would appreciate any suggestions. Would love to hear "You?re doing it wrong, use this set of jpackage options"! > > Otherwise, suggestions or pointers to any on-line documents that would help would be great. (Have been Googling everything about this, but almost all of the "answers" assume that you are using Xcode and tell you what parameters to set - nothing about the resulting in-the-trenches process that Xcode then executes.) > > Thanks, > > John Crowley > Charlotte, NC > 203-856-2396 > j.crowley at computer.org > > > > > From info at j-kuhn.de Mon Feb 1 15:19:54 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Mon, 1 Feb 2021 16:19:54 +0100 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <1915323937.509806.1612191512611.JavaMail.zimbra@u-pem.fr> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> <1915323937.509806.1612191512611.JavaMail.zimbra@u-pem.fr> Message-ID: <633dd29b-71e7-8212-e98c-b577f5733394@j-kuhn.de> On 01-Feb-21 15:58, Remi Forax wrote: > ----- Mail original ----- >> De: "Johannes Kuhn" >> ?: "core-libs-dev" >> Envoy?: Lundi 1 F?vrier 2021 15:50:51 >> Objet: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle > >> While implementing a prototype for JDK-8242888 (Convert dynamic proxy to >> hidden classes) I came across the problem that hidden classes can't be >> mentioned in the constant pool, breaking the constructor for serialization. >> >> To remedy that problem, I used a MHConstructorAccessor which delegates >> the actual work to MethodHandles - not unlike what JDK-6824466 suggests. >> >> As there has been previous work in that area, (I am aware of at least 3 >> independently developed prototypes for that bug/enchantment) I would >> like to ask a few questions around it: >> >> >> >> 1) What are the challenges? >> >> From the bug I could infer, that it's cold start is slower than >> NativeMethodAccessor, but still faster than the generated (bytecode >> spinning) accessors. >> >> 2) Are there any roadblocks that prevent replacing the >> MethodAccessorGenerator with accessors that use MethodHandles? >> >> From my limited tests, it appears to work well enough. >> >> 3) Should I try to implement it? >> >> >> >> From my POV, replacing MethodAccessorGenerator with accessors that >> delegate to MethodHandles has a few benefits: >> >> * Support for hidden classes. (Currently fallback to native accessors) >> * Removal of MethodAccessorGenerator (which is old and clunky) > > Hi Johannes, > the native accessors doesn't play with loom (a C stack frame in the middle of the Java stack can not be moved) so it doesn't seem to be a good idea to rely on the native accessors for hidden classes. > >> >> - Johannes > > R?mi > Thanks R?mi. The problem here is that (according to Peter Levart tests), the cold use of a MHMethodAccessor is 11x as expensive as using the native accessor. In some way, it sill makes sense to keep the native accessor around, at least during startup. On the other hand, I heard that there have been some improvements on the AppCDS w.r.t MethodHandles, but I'm out of the loop there. An other problem with completely replacing the native accessors is some bootstrap problem - if certain flags are set (some of them are used to build the CDS), then the java.lang.invoke infrastructure tries to write stuff to System.out. But to initialize System.out, the charset has to be constructed, which relies on reflection. I can see some potential in improving the initialization of the standard charset, but it's out of the scope here. Apropos scope: I try to narrow the scope down to "replace MethodAccessorGenerator with accessors that delegate to MethodHandles". Once this is done, then additional improvements can be made - including some that take loom into account. Or adding some @Stable/@ForceInline stuff so the JIT can better optimize reflective calls. But currently (didn't look into the loom source) there are only two strategies: Native accessor (bad for loom) or generated (bytecode spinning, doesn't work with hidden classes). So, with loom and hidden classes you get the worst of both worlds. MethodHandles solve that. - Johannes From mik3hall at gmail.com Mon Feb 1 15:48:00 2021 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 1 Feb 2021 09:48:00 -0600 Subject: jpackage problem submitting to Apple Store In-Reply-To: References: <511A88CF-2D6F-4B04-81BE-5BB95B750754@computer.org> Message-ID: <6001D192-F0D9-4AAC-9F0B-1DA3154479FC@gmail.com> > On Feb 1, 2021, at 9:02 AM, Andy Herrick wrote: > > This step is required to post app on web where it can be downloaded and run on other machines running MacOS Catalina or later. This is probably all I?d be looking at for now. I?m looking at an app I wrote a year or two back with downloaded images and sounds. I read somewhere Apple rejected someone?s app because they couldn?t prove something they used was public domain. I am sure I couldn?t prove that for everything I used. From asemenyuk at openjdk.java.net Mon Feb 1 16:06:54 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 1 Feb 2021 16:06:54 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: <_A4zwqAepdFE8_cZLjLg0oT-ic7eqE3T_UdStcDwZX4=.e5258e58-e08c-462e-beba-13d5dc335061@github.com> On Mon, 1 Feb 2021 12:16:09 GMT, Magnus Ihse Bursie wrote: >> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8254702: jpackage app launcher crashes on CentOS > > make/modules/jdk.jpackage/Lib.gmk line 61: > >> 59: JPACKAGE_OUTPUT_DIR := $(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources >> 60: JPACKAGE_CXXFLAGS_windows := -EHsc -DUNICODE -D_UNICODE >> 61: JPACKAGE_CFLAGS_windows := -DUNICODE -D_UNICODE > > Why is this change modifying Windows? I thought it was supposed to be a linux-only fix..? There is new shared JvmlLauncherLib.c file. This new make variable is to setup complier for this file on Windows. The functional change is Linux-only, however code base code reshuffled on all platforms. > make/modules/jdk.jpackage/Lib.gmk line 65: > >> 63: )) >> 64: >> 65: $(BUILD_JPACKAGE_APPLAUNCHEREXE): $(call FindLib, java.base, java) > > Why did you remove this dependency? I moved it to the bottom of the file making all artifacts produced by make/modules/jdk.jpackage/Lib.gmk depend on java.bas and java. There is `$(JPACKAGE_TARGETS): $(call FindLib, java.base, java)` at the bottom of the file. > make/modules/jdk.jpackage/Lib.gmk line 106: > >> 104: CFLAGS_linux := -Wno-format-nonliteral, \ >> 105: LDFLAGS := $(LDFLAGS_JDKLIB) \ >> 106: -Wl$(COMMA)--version-script=$(TOPDIR)/make/modules/$(MODULE)/applauncherlib.ld-version-script, \ > > We should really not be using linker scripts. I did not understand your comment in the linker script -- was it only needed to handle your personal build environment? If so, you need to fix your build environment instead. Yeh, I found that linker script is needed only in my local build env. I'll remove it then. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From raffaello.giulietti at gmail.com Mon Feb 1 16:10:10 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 1 Feb 2021 17:10:10 +0100 Subject: Comment on 8260692: Matematically wrong implementations of RoundingMode.HALF_UP and .HALF_DOWN Message-ID: <2cd92fa9-35fa-4471-c3fe-8b9ac796df7d@gmail.com> Hi, in my opinion, and contrary to the report [1], the described issue is not a bug. While the wording used in the spec of java.math.RoundingMode could be improved, it is nonetheless clear enough to avoid any confusion about what HALF_DOWN and HALF_UP mean in this context. The actual values reported are all correct while the expected ones are not. I think the issue can be closed as not relevant. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8260692 From asemenyuk at openjdk.java.net Mon Feb 1 16:20:51 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 1 Feb 2021 16:20:51 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 12:19:56 GMT, Magnus Ihse Bursie wrote: >> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8254702: jpackage app launcher crashes on CentOS > > Changes requested by ihse (Reviewer). "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. I'll rename applauncherlibcommon in libapplaunchercommon and applauncherlib in libapplauncher in the next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From mandy.chung at oracle.com Mon Feb 1 17:37:22 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 Feb 2021 09:37:22 -0800 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> Message-ID: <915ac8c0-e4b1-f5a4-8614-4e45adecb211@oracle.com> Hi Johannes, I believe you are aware of the prototype I'm working on: ??? https://github.com/mlchung/jdk/tree/method-invoke My prototype so far replaces method and fields but not constructors yet.?? You are welcome to contribute. My main motivation of doing this is to get rid of the old clunky bytecode generator and core reflection will be built atop on method handles.?? This would greatly simplify the work to add support for a new feature for example Valhalla primitive classes only in method handles.? ? I plan to keep the native method accessor? for startup use (or switch to method handles when module system is initialized). Mandy On 2/1/21 6:50 AM, Johannes Kuhn wrote: > While implementing a prototype for JDK-8242888 (Convert dynamic proxy > to hidden classes) I came across the problem that hidden classes can't > be mentioned in the constant pool, breaking the constructor for > serialization. > > To remedy that problem, I used a MHConstructorAccessor which delegates > the actual work to MethodHandles - not unlike what JDK-6824466 suggests. > > As there has been previous work in that area, (I am aware of at least > 3 independently developed prototypes for that bug/enchantment) I would > like to ask a few questions around it: > > > > 1) What are the challenges? > > From the bug I could infer, that it's cold start is slower than > NativeMethodAccessor, but still faster than the generated (bytecode > spinning) accessors. > > 2) Are there any roadblocks that prevent replacing the > MethodAccessorGenerator with accessors that use MethodHandles? > > From my limited tests, it appears to work well enough. > > 3) Should I try to implement it? > > > > From my POV, replacing MethodAccessorGenerator with accessors that > delegate to MethodHandles has a few benefits: > > * Support for hidden classes. (Currently fallback to native accessors) > * Removal of MethodAccessorGenerator (which is old and clunky) > > - Johannes From joe.darcy at oracle.com Mon Feb 1 17:47:47 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 1 Feb 2021 09:47:47 -0800 Subject: Comment on 8260692: Matematically wrong implementations of RoundingMode.HALF_UP and .HALF_DOWN In-Reply-To: <2cd92fa9-35fa-4471-c3fe-8b9ac796df7d@gmail.com> References: <2cd92fa9-35fa-4471-c3fe-8b9ac796df7d@gmail.com> Message-ID: <477fff60-f14b-e9f8-64f0-315b6a482211@oracle.com> Hi Raffaello, I agree with your analysis and closed the bug noting some additional history. Cheers, -Joe On 2/1/2021 8:10 AM, Raffaello Giulietti wrote: > Hi, > > in my opinion, and contrary to the report [1], the described issue is > not a bug. > > While the wording used in the spec of java.math.RoundingMode could be > improved, it is nonetheless clear enough to avoid any confusion about > what HALF_DOWN and HALF_UP mean in this context. The actual values > reported are all correct while the expected ones are not. > > I think the issue can be closed as not relevant. > > > Greetings > Raffaello > > ---- > > [1] https://bugs.openjdk.java.net/browse/JDK-8260692 From info at j-kuhn.de Mon Feb 1 17:59:44 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Mon, 1 Feb 2021 18:59:44 +0100 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <915ac8c0-e4b1-f5a4-8614-4e45adecb211@oracle.com> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> <915ac8c0-e4b1-f5a4-8614-4e45adecb211@oracle.com> Message-ID: <7463976a-2078-2318-0a1d-bf6df1fcd3ee@j-kuhn.de> Thanks Mandy. Yes, the 3 prototypes I mentioned were yours, Peter Levart's, and my own. (My prototype is at https://github.com/DasBrain/jdk/tree/reflection-MHaccessors - I hit an boostrap problem, build a workaround that I don't really like, so I stopped working on that.) I agree on your goals, they are the same as mine. For the constructor story, well, that is a prerequisite for the hidden proxy classes. I'll take an other look at your implementation, and maybe open a pull request against your repo. Current approach is to keep the scope small - just replacing the old generated accessors with method handle based ones. Even this "small" change is IMHO worthwhile: * Getting rid of the old MethodAccessorGenerator (I don't want to maintain it, and if I had to, then moving to ASM would be a step forward) * Better performance on calling methods from hidden classes. (Loom doesn't like native frames on the stack) * Prerequisite for further enchantments, such as hidden proxy classes, alternatives for reflective @CS and possible performance improvements using @Stable/@ForceInline. It's just - it's an old bug, and other people already did try some stuff on it. So I try to learn from their experience and try to understand what roadblocks they hit first. No need to repeat the mistakes others already made. - Johannes On 01-Feb-21 18:37, Mandy Chung wrote: > Hi Johannes, > > I believe you are aware of the prototype I'm working on: > https://github.com/mlchung/jdk/tree/method-invoke > > My prototype so far replaces method and fields but not constructors > yet.?? You are welcome to contribute. > > My main motivation of doing this is to get rid of the old clunky > bytecode generator and core reflection will be built atop on method > handles.?? This would greatly simplify the work to add support for a new > feature for example Valhalla primitive classes only in method handles. > ? I plan to keep the native method accessor? for startup use (or switch > to method handles when module system is initialized). > > Mandy > > On 2/1/21 6:50 AM, Johannes Kuhn wrote: >> While implementing a prototype for JDK-8242888 (Convert dynamic proxy >> to hidden classes) I came across the problem that hidden classes can't >> be mentioned in the constant pool, breaking the constructor for >> serialization. >> >> To remedy that problem, I used a MHConstructorAccessor which delegates >> the actual work to MethodHandles - not unlike what JDK-6824466 suggests. >> >> As there has been previous work in that area, (I am aware of at least >> 3 independently developed prototypes for that bug/enchantment) I would >> like to ask a few questions around it: >> >> >> >> 1) What are the challenges? >> >> From the bug I could infer, that it's cold start is slower than >> NativeMethodAccessor, but still faster than the generated (bytecode >> spinning) accessors. >> >> 2) Are there any roadblocks that prevent replacing the >> MethodAccessorGenerator with accessors that use MethodHandles? >> >> From my limited tests, it appears to work well enough. >> >> 3) Should I try to implement it? >> >> >> >> From my POV, replacing MethodAccessorGenerator with accessors that >> delegate to MethodHandles has a few benefits: >> >> * Support for hidden classes. (Currently fallback to native accessors) >> * Removal of MethodAccessorGenerator (which is old and clunky) >> >> - Johannes > From asemenyuk at openjdk.java.net Mon Feb 1 18:11:27 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 1 Feb 2021 18:11:27 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v3] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: 8254702: jpackage app launcher crashes on CentOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2320/files - new: https://git.openjdk.java.net/jdk/pull/2320/files/b493bcfd..91744255 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=01-02 Stats: 9 lines in 13 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From erikj at openjdk.java.net Mon Feb 1 18:26:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 1 Feb 2021 18:26:44 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: Message-ID: <4vgEo6OKMRjvH6Uo_PsYddUZ-XTyIe8PKKuUGxoXP3A=.4723b577-89b3-4c0e-bf96-1f17a47313a8@github.com> On Mon, 1 Feb 2021 16:17:35 GMT, Alexey Semenyuk wrote: > "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. We pick compiler based on file suffix, not directory, so it shouldn't matter where you put a .c file, it should always be compiled with gcc and .cpp files with g++. Which compiler is used to launch the linker can however differ. That's configured for each SetupNativeCompilation call with the different TOOLCHAIN settings. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From asemenyuk at openjdk.java.net Mon Feb 1 18:38:44 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 1 Feb 2021 18:38:44 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: <4vgEo6OKMRjvH6Uo_PsYddUZ-XTyIe8PKKuUGxoXP3A=.4723b577-89b3-4c0e-bf96-1f17a47313a8@github.com> References: <4vgEo6OKMRjvH6Uo_PsYddUZ-XTyIe8PKKuUGxoXP3A=.4723b577-89b3-4c0e-bf96-1f17a47313a8@github.com> Message-ID: On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote: >> "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. >> >> I'll rename applauncherlibcommon in libapplaunchercommon and applauncherlib in libapplauncher in the next commit. > >> "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. > > We pick compiler based on file suffix, not directory, so it shouldn't matter where you put a .c file, it should always be compiled with gcc and .cpp files with g++. Which compiler is used to launch the linker can however differ. That's configured for each SetupNativeCompilation call with the different TOOLCHAIN settings. Erik, thank you for explanation. The launcher on Linux should not be linked with c++ runtime, that is why TOOLCHAIN_DEFAULT is used at a value for TOOLCHAIN property in BUILD_JPACKAGE_APPLAUNCHEREXE target on Linux. Will SetupNativeCompilation work if `TOOLCHAIN=TOOLCHAIN_DEFAULT` and there are .cpp sources are in directories passed in `SRC` property of SetupNativeCompilation? Will it try to compile these sources? If it will ignore them and pick only .c files, that would be perfect. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From aph at openjdk.java.net Mon Feb 1 18:49:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 1 Feb 2021 18:49:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Sun, 31 Jan 2021 20:14:01 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov 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 jdk-macos > - Update copyright year for BsdAARCH64ThreadContext.java > - Fix inclusing of StubRoutines header > - Redo buildsys fix > - Revert harfbuzz changes, disable warnings for it > - Little adjustement of SlowSignatureHandler > - Partially bring previous commit > - Revert "Address feedback for signature generators" > > This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. > - Refactor CDS disabling > - Redo builsys support for aarch64-darwin > - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 84: > 82: // on stack. Natural alignment for types are still in place, > 83: // for example double/long should be 8 bytes alligned > 84: This comment is a bit confusing because it's no longer #ifdef APPLE. Better move it up to Line 41. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 352: > 350: > 351: #ifdef __APPLE__ > 352: virtual void pass_byte() Please remove ```#ifdef __APPLE__``` around this region. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: > 837: // The code unable to handle this, bailout. > 838: return -1; > 839: #endif This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From iklam at openjdk.java.net Mon Feb 1 18:52:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 1 Feb 2021 18:52:52 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX Message-ID: - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h ------------- Commit messages: - 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX Changes: https://git.openjdk.java.net/jdk/pull/2338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260193 Stats: 110 lines in 3 files changed: 0 ins; 109 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2338/head:pull/2338 PR: https://git.openjdk.java.net/jdk/pull/2338 From raffaello.giulietti at gmail.com Mon Feb 1 19:13:50 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 1 Feb 2021 20:13:50 +0100 Subject: Comment on 8259896: Base64 MIME decoder should allow unrecognised characters within padding Message-ID: <7c73968d-1961-6e1f-8694-a008b3bdf551@gmail.com> Hi, in my opinion, the reporter of [1] is right in requiring that extraneous characters be discarded, even inside the padding. Indeed, the first full paragraph on [2] reads: "Any characters outside of the base64 alphabet are to be ignored in base64-encoded data." where "the base64 alphabet" also includes the padding character '=' and "base64-encoded data" extends to padding as well, because padding is an essential part of encoding. The legitimate doubt expressed in comment [3] should thus be solved in favor of a bug fix. My 2 cents Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8259896 [2] https://tools.ietf.org/html/rfc2045#page-26 [3] https://bugs.openjdk.java.net/browse/JDK-8259896?focusedCommentId=14395485&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14395485 From erik.joelsson at oracle.com Mon Feb 1 19:19:29 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 1 Feb 2021 11:19:29 -0800 Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: <4vgEo6OKMRjvH6Uo_PsYddUZ-XTyIe8PKKuUGxoXP3A=.4723b577-89b3-4c0e-bf96-1f17a47313a8@github.com> Message-ID: On 2021-02-01 10:38, Alexey Semenyuk wrote: > On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote: > >>> "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. >>> >>> I'll rename applauncherlibcommon in libapplaunchercommon and applauncherlib in libapplauncher in the next commit. >>> "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. >> We pick compiler based on file suffix, not directory, so it shouldn't matter where you put a .c file, it should always be compiled with gcc and .cpp files with g++. Which compiler is used to launch the linker can however differ. That's configured for each SetupNativeCompilation call with the different TOOLCHAIN settings. > Erik, thank you for explanation. > > The launcher on Linux should not be linked with c++ runtime, that is why TOOLCHAIN_DEFAULT is used at a value for TOOLCHAIN property in BUILD_JPACKAGE_APPLAUNCHEREXE target on Linux. > > Will SetupNativeCompilation work if `TOOLCHAIN=TOOLCHAIN_DEFAULT` and there are .cpp sources are in directories passed in `SRC` property of SetupNativeCompilation? Will it try to compile these sources? If it will ignore them and pick only .c files, that would be perfect. SetupNativeCompilation will by default include all src files found in any directory given to SRC, recursively. You can use EXCLUDES, EXCLUDE_FILES and EXCLUDE_PATTERN to exclude files or directories from SRC. You can also use EXTRA_FILES to pick specific files outside of any directory in SRC. Sorting files in separate directories or using EXCLUDE*/EXTRA_FILES are both possible and picking the right solution is mostly down to taste. /Erik > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2320 From bpb at openjdk.java.net Mon Feb 1 19:23:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 1 Feb 2021 19:23:39 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: Message-ID: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? > > As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. > > Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. > > Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. > > Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. > > Given the nature of this issue, I haven't added any jtreg test for this change. The code change looks all right. It would be better if there were a test, but apparently this might depend on the user who runs the test not having registry access rights. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From martin at openjdk.java.net Mon Feb 1 19:46:40 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 1 Feb 2021 19:46:40 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: <_9v8vIySf_ojlNxz-vu0PWbcmG11CxgoEPorRtDG0QI=.5d407ec8-286a-4e40-9d02-52a0ff4a51f6@github.com> On Mon, 1 Feb 2021 10:22:14 GMT, Claes Redestad wrote: >> @amalloy - you are invited to comment on regex content >> @cl4es @shipilev - you are invited to point out my jmh bad practices > > The assertion discussion aside, the micros look fine to me. > > With an eye towards reducing total run time I'd ask you to consider if all parameter combinations are useful or if we can get the same value after some pruning. @stuart-marks you are invited to review ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From alanb at openjdk.java.net Mon Feb 1 19:54:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 1 Feb 2021 19:54:41 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:40:54 GMT, Ioi Lam wrote: > - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. > - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From lfoltan at openjdk.java.net Mon Feb 1 19:58:39 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 1 Feb 2021 19:58:39 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:40:54 GMT, Ioi Lam wrote: > - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. > - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h Marked as reviewed by lfoltan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From iklam at openjdk.java.net Mon Feb 1 20:10:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 1 Feb 2021 20:10:58 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: References: Message-ID: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> > - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. > - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed macos build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2338/files - new: https://git.openjdk.java.net/jdk/pull/2338/files/c0307e7d..3a6415eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2338&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2338&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2338/head:pull/2338 PR: https://git.openjdk.java.net/jdk/pull/2338 From github.com+34924738+mahendrachhipa at openjdk.java.net Mon Feb 1 20:16:58 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Mon, 1 Feb 2021 20:16:58 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v7] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/40ba2b3b..0cbee711 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=05-06 Stats: 138 lines in 2 files changed: 51 ins; 46 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From github.com+34924738+mahendrachhipa at openjdk.java.net Mon Feb 1 20:27:00 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Mon, 1 Feb 2021 20:27:00 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v8] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/0cbee711..9a280259 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=06-07 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From andrew at openjdk.java.net Mon Feb 1 20:29:39 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Mon, 1 Feb 2021 20:29:39 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Tue, 12 Jan 2021 14:29:28 GMT, Severin Gehwolf wrote: > Anybody willing to review this? I can have a go. I have two main concerns: 1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too. 2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like: if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From gziemski at openjdk.java.net Mon Feb 1 20:32:41 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 1 Feb 2021 20:32:41 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> Message-ID: On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote: >> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. >> - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed macos build Changes requested by gziemski (Committer). src/java.base/share/native/libjava/check_version.c line 33: > 31: DEF_JNI_OnLoad(JavaVM *vm, void *reserved) > 32: { > 33: return JNI_VERSION_1_2; This leaves an entire file with one trivial function implementation. Can we remove the file and implement `DEF_JNI_OnLoad()` in `jni_util.h` (or some other existing suitable file) ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From mchung at openjdk.java.net Mon Feb 1 20:45:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 1 Feb 2021 20:45:45 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v8] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 20:27:00 GMT, Mahendra Chhipa wrote: >> https://bugs.openjdk.java.net/browse/JDK-8183372 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the review comments. Thanks for the update. This is much cleaner. test/jdk/java/lang/Class/forName/NonJavaNames.java line 154: > 152: @DataProvider(name = "badNonJavaClassNames") > 153: Object[][] getBadNonJavaClassNames() { > 154: return new Object[][] {{";"}, {"["}, {"."}}; Nit: one line per test (i.e. make it multiple lines) test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 42: > 40: > 41: /* > 42: * @test Nit: suggest to move this comment block to the top before all imports. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2170 From martin at openjdk.java.net Mon Feb 1 20:54:40 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 1 Feb 2021 20:54:40 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 10:22:14 GMT, Claes Redestad wrote: >> @amalloy - you are invited to comment on regex content >> @cl4es @shipilev - you are invited to point out my jmh bad practices > > The assertion discussion aside, the micros look fine to me. > > With an eye towards reducing total run time I'd ask you to consider if all parameter combinations are useful or if we can get the same value after some pruning. @cl4es I agree pruning is a good idea. I settled on 3 data points with 16x separations as good enough to clearly show the difference between O(1) O(N) O(N^2) and O(2^N) (although O(2^N) would "run forever"). (although ... please tell me you're not actually running these benchmarks in an automated fashion ... too expensive, and needs a human to interpret the results) ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From iklam at openjdk.java.net Mon Feb 1 20:57:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 1 Feb 2021 20:57:44 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> Message-ID: <3s1-hVjGvofyZ6o7jh6ayZWMp_RkPlt1Juig5U9zQfM=.3adf577e-6ee6-4f29-ba22-c7d15e742f3e@github.com> On Mon, 1 Feb 2021 20:29:10 GMT, Gerard Ziemski wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed macos build > > src/java.base/share/native/libjava/check_version.c line 33: > >> 31: DEF_JNI_OnLoad(JavaVM *vm, void *reserved) >> 32: { >> 33: return JNI_VERSION_1_2; > > This leaves an entire file with one trivial function implementation. Can we remove the file and implement `DEF_JNI_OnLoad()` in `jni_util.h` (or some other existing suitable file) ? I am not sure if jni_utils.c is the right file (it defines the `JNU_XXX` functions that are used by other shared libraries). There are other .c files that have trivial `DEF_JNI_OnLoad` functions (e.g., java.base/share/native/libnio/nio_util.c). @AlanBateman do you have any suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From github.com+34924738+mahendrachhipa at openjdk.java.net Mon Feb 1 21:46:00 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Mon, 1 Feb 2021 21:46:00 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v9] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented the review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/9a280259..9ff23ef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=07-08 Stats: 28 lines in 2 files changed: 14 ins; 11 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From mchung at openjdk.java.net Mon Feb 1 21:57:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 1 Feb 2021 21:57:45 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v9] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 21:46:00 GMT, Mahendra Chhipa wrote: >> https://bugs.openjdk.java.net/browse/JDK-8183372 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the review comments. Marked as reviewed by mchung (Reviewer). test/jdk/java/lang/Class/forName/NonJavaNames.java line 119: > 117: > 118: @Test(dataProvider = "goodNonJavaClassNames") > 119: public void testGoodNonJavaClassNames(String name) throws Throwable { s/Throwable/ClassFileNotFoundException/ test/jdk/java/lang/Class/forName/NonJavaNames.java line 129: > 127: try { > 128: Class.forName(name); > 129: } catch (Exception e) { s/Exception/ClassNotFoundException/ ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From dcubed at openjdk.java.net Mon Feb 1 22:13:54 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:13:54 GMT Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java Message-ID: A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the ProblemList. It was removed in error (see the bug for the details). ------------- Commit messages: - 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java Changes: https://git.openjdk.java.net/jdk/pull/2341/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260860 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2341/head:pull/2341 PR: https://git.openjdk.java.net/jdk/pull/2341 From dcubed at openjdk.java.net Mon Feb 1 22:18:45 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:18:45 GMT Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:06:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the > ProblemList. It was removed in error (see the bug for the details). @JimLaskey or @sundararajana - If either if you are on-line and can review this, I would appreciate it. Jim, you reviewed it the last time I ProblemListed it. Sundar, you took the test off the ProblemList before https://bugs.openjdk.java.net/browse/JDK-8247407 was fixed so we have failures again. ------------- PR: https://git.openjdk.java.net/jdk/pull/2341 From github.com+34924738+mahendrachhipa at openjdk.java.net Mon Feb 1 22:23:02 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Mon, 1 Feb 2021 22:23:02 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v10] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: throwing the specific exceptions. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/9ff23ef5..320b3054 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From dholmes at openjdk.java.net Mon Feb 1 22:23:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 1 Feb 2021 22:23:42 GMT Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:06:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the > ProblemList. It was removed in error (see the bug for the details). LGTM ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2341 From claes.redestad at oracle.com Mon Feb 1 22:27:04 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 1 Feb 2021 23:27:04 +0100 Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: <5901f0fb-256d-52d8-8112-52432c7904e6@oracle.com> On 2021-02-01 21:54, Martin Buchholz wrote: > On Mon, 1 Feb 2021 10:22:14 GMT, Claes Redestad wrote: > >>> @amalloy - you are invited to comment on regex content >>> @cl4es @shipilev - you are invited to point out my jmh bad practices >> >> The assertion discussion aside, the micros look fine to me. >> >> With an eye towards reducing total run time I'd ask you to consider if all parameter combinations are useful or if we can get the same value after some pruning. > > @cl4es I agree pruning is a good idea. I settled on 3 data points with 16x separations as good enough to clearly show the difference between O(1) O(N) O(N^2) and O(2^N) (although O(2^N) would "run forever"). > > (although ... please tell me you're not actually running these benchmarks in an automated fashion ... too expensive, and needs a human to interpret the results) No, we don't automatically pick up and run new microbenchmarks, but I still think it's good if the checked in parameter combinations are a reasonable approximation of what _someone_ should be running every now and then. A manual exploration of a new set of micros would naturally start with the default config, so if such a config runs forever, that would be poor ergonomics IMHO. I don't think such configurations should be checked in in an active state. I'd opt for a comment on how to produce a regex that would exponentially backtrack in such ways, for those who might want to explore such corner cases. (It would be nice with some JMH analogue of jtreg's "manual", so that one can mark benchmarks that should are excluded from automatic or wildcard executions. Maybe there exists some way to do this already?) > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1940 > From dholmes at openjdk.java.net Mon Feb 1 22:28:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 1 Feb 2021 22:28:41 GMT Subject: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues [v2] In-Reply-To: References: <69VG2pHXENcmbm8jrgBnSc7c5mkboGixGiMKNtaYePE=.43bcec75-2960-46b3-9dab-1a11576c3ced@github.com> Message-ID: On Mon, 1 Feb 2021 11:41:43 GMT, Alan Bateman wrote: >> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed CompressorPluginTest.java from ProblemList.txt > > Marked as reviewed by alanb (Reviewer). Note the test has been added back to the ProblemList due to failures in the CI. ------------- PR: https://git.openjdk.java.net/jdk/pull/2091 From dcubed at openjdk.java.net Mon Feb 1 22:34:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:34:41 GMT Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:21:06 GMT, David Holmes wrote: >> A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the >> ProblemList. It was removed in error (see the bug for the details). > > LGTM @dholmes-ora - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2341 From dholmes at openjdk.java.net Mon Feb 1 22:48:45 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 1 Feb 2021 22:48:45 GMT Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16 In-Reply-To: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> References: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> Message-ID: <_IdMSe0Y15bWzd3cgSv1-izf-0qxvEguB_NOhviVkSs=.7e14f316-a590-44a6-8b9e-fb1cb92331e4@github.com> On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote: > Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. Thanks for doing this Magnus! I had overlooked the fact we would need to re-run this in 2021 regardless of whether there were any content changes to propagate. Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/142 From dcubed at openjdk.java.net Mon Feb 1 22:55:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Feb 2021 22:55:41 GMT Subject: Integrated: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:06:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the > ProblemList. It was removed in error (see the bug for the details). This pull request has now been integrated. Changeset: 9880c4cd Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/9880c4cd Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2341 From talden at gmail.com Mon Feb 1 23:01:47 2021 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Tue, 2 Feb 2021 12:01:47 +1300 Subject: Why does Set.of disallow duplicate elements? In-Reply-To: <1964605040.2099457.1612128924150.JavaMail.zimbra@u-pem.fr> References: <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr> <1964605040.2099457.1612128924150.JavaMail.zimbra@u-pem.fr> Message-ID: Dave, || Dave said... || Okay, I understand this reasoning, but when you want to construct a Set from an array, you might be tempted to use Set.of(...) because it looks like it supports an || array and indeed, you can do Set.of(new int[] {1, 2 }) I believe? || || Maybe this is just a quirk because of how varargs work. | R?mi said... | Set.of(int[]) will call Set.of(E) with E being an int[]. | but | Set.of(new Integer[] { ... }) calls Set.of(...). | | Yes, exactly, it's a known issue with varargs, you have no way to say, i don't want this varargs to be called with an array. I think the confusion is the interaction of boxing and varargs. > List list = List.of(1, 2); is actually, once auto-boxing is applied by the compiler, executed as... > List list = List.of(Integer.valueOf(1), Integer.valueOf(2)); So the equivalent explicit array form should use `Integer[]` not `int[]`... > Integer[] numbers = new Integer[] {1, 2}; > List list = List.of(numbers); Interestingly, if you actually wanted a `List` you would then need to say > Integer[] numbers = new Integer[] {1, 2}; > List list = List.of(numbers); Which is explicitly telling the compiler what the type arguments are for this invocation of the generic method 'of'' (rather than allowing it to use type-inference) Regarding the use of `Set.copyOf(Arrays.asList(...))`. I do wonder about improving the ceremony (because I agree that we want an obvious way of getting immutable Sets from non-unique inputs) by following the pattern presented in Optional (`Optional.of` and `Optional.ofNullable`) and providing `Set.of` and `Set.ofMaybeUnique` (better name needed - 'ofOptionallyUnique'?) - to which the implementation could just be `Set.copyOf(Arrays.asList(args))` (unless a more efficient path proves valuable). `Arrays.asList(...array...)` is not all that expensive. It is _not_ an ArrayList but a much simpler type with rather trivial implementations for most methods (and 'always throws' implementations for methods that are unsupported). So not only does it mean that there's no copying occuring to make the list but it's even possible that JIT manages enough specialisation and inlining to elide the allocation entirely (though in practice this doesn't occur as often as we might like). -- Aaron Scott-Boddendijk On Mon, Feb 1, 2021 at 10:35 AM wrote: > > > > > > De: "dfranken jdk" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Dimanche 31 Janvier 2021 13:54:44 > Objet: Re: Why does Set.of disallow duplicate elements? > > > > > BQ_BEGIN > > Okay, I understand this reasoning, but when you want to construct a Set > from an array, you might be tempted to use Set.of(...) because it looks > like it supports an array and indeed, you can do Set.of(new int[] {1, 2 }) > I believe? > > BQ_END > > Set.of(int[]) will call Set.of(E) with E being an int[]. > but > Set.of(new Integer[] { ... }) calls Set.of(...). > > > BQ_BEGIN > > > Maybe this is just a quirk because of how varargs work. > > BQ_END > > Yes, exactly, it's a known issue with varargs, you have no way to say, i > don't want this varargs to be called with an array. > > > BQ_BEGIN > > > I wondered if there was a canonical way to create a Set from an array, but > couldn't find it, maybe I am missing something? > I did notice Arrays.asList exists (which makes sense because it creates an > ArrayList backed by the array), but not Arrays.asSet. > > BQ_END > > asList() reuse the same backing array, you can not do that with asSet() or > contains() will be in O(n) in the worst case. > > > BQ_BEGIN > > > So the way I would create a Set from an array would be either > Arrays.stream(myArr).collect(Collectors.toUnmodifiableSet()) or new > HashSet<>(Arrays.asList(myArray)) or Set.copyOf(Arrays.asList(myArray)). > > BQ_END > > yes, the last one is the easy way to create an unmodifiable set from an > array. > > > BQ_BEGIN > > > I'm not saying the way it is currently implemented is wrong, it's just > something which can suprise developers as it surprised me. :) > > BQ_END > > Arrays are currently second class citizen in Java, because they are always > modifiable and always covariant (String[] can be seen as a Object[]). > We have talked several times to introduce new variants of arrays, > non-modifiable one, non-covariant one, etc under the name Array 2.0, but > Valhalla generics is a blocker for that project. > Once Valhalla is done, it may be a follow up. > > > BQ_BEGIN > > > Kind regards, > > Dave > > BQ_END > > > regards, > R?mi > > > BQ_BEGIN > > > > Op za 30 jan. 2021 om 21:30 schreef Remi Forax < [ mailto: > forax at univ-mlv.fr | forax at univ-mlv.fr ] >: > > BQ_BEGIN > Set.of() is the closest way we've got to a literal Set without having > introduced a special syntax for that in the language. > > The idea is that if you conceptually want to write > Set set = { "hello", "world" }; > instead, you write > Set set = Set.of("hello", "world"); > > In that context, it makes sense to reject Set constructed with the same > element twice because this is usually a programming error. > So > Set.of("hello", "hello") > throws an IAE. > > If you want a Set from a collection of elements, you can use > Set.copyOf(List.of("hello", "hello")) > > regards, > R?mi > > ----- Mail original ----- > > De: "dfranken jdk" < [ mailto:dfranken.jdk at gmail.com | > dfranken.jdk at gmail.com ] > > > ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net | > core-libs-dev at openjdk.java.net ] > > > Envoy?: Samedi 30 Janvier 2021 19:30:06 > > Objet: Why does Set.of disallow duplicate elements? > > > Dear users, > > > > While looking at the implementation of Set.of(...) I noticed that > > duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an > > IllegalArgumentException. Why has it been decided to do this? > > > > My expectation was that duplicates would simply be removed. > > > > If I do for instance new HashSet<>() > > it works and duplicates are removed. To me, it looks a bit inconsistent > > to have duplicates removed for a collection passed in the constructor, > > but not for a collection (even though it is a vararg array) passed to a > > static factory method. > > > > Kind regards, > > > > Dave Franken > > BQ_END > > > BQ_END > > > From mchung at openjdk.java.net Mon Feb 1 23:31:44 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 1 Feb 2021 23:31:44 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v9] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 21:54:50 GMT, Mandy Chung wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > Marked as reviewed by mchung (Reviewer). I think Brent wants to review it. I will let Brent to sponsor you. ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From almatvee at openjdk.java.net Mon Feb 1 23:46:58 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 1 Feb 2021 23:46:58 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' Message-ID: We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. ------------- Commit messages: - 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject disk2 - Resource busy' Changes: https://git.openjdk.java.net/jdk/pull/2345/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2345&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259570 Stats: 162 lines in 3 files changed: 151 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2345/head:pull/2345 PR: https://git.openjdk.java.net/jdk/pull/2345 From bchristi at openjdk.java.net Mon Feb 1 23:49:43 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 1 Feb 2021 23:49:43 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v4] In-Reply-To: References: Message-ID: <9MSS6_4lYH9acY6W48QdC3ZZdYn2q5OeqsTUY0C7D_c=.de14909a-8309-4247-8da8-843623b2dc67@github.com> On Wed, 27 Jan 2021 22:44:00 GMT, Mahendra Chhipa wrote: >> https://bugs.openjdk.java.net/browse/JDK-8183372 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the review comments. Changes requested by bchristi (Reviewer). test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 157: > 155: > 156: private void match(final String actual, final String expected) { > 157: System.out.println("actual:" + actual + "expected:" + expected); It would be good to insert a space before `expected:` test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 158: > 156: private void match(final String actual, final String expected) { > 157: System.out.println("actual:" + actual + "expected:" + expected); > 158: assert ((actual == null && expected == null) || actual.equals(expected.trim())); I think we need to figure out where the extra space is coming from, if the test worked before, but now fails without adding the `trim()`. Also, I think it would be better to throw an exception instead of using `assert`, so the test works with or without assertions being enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From bchristi at openjdk.java.net Mon Feb 1 23:49:44 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 1 Feb 2021 23:49:44 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v4] In-Reply-To: <9MSS6_4lYH9acY6W48QdC3ZZdYn2q5OeqsTUY0C7D_c=.de14909a-8309-4247-8da8-843623b2dc67@github.com> References: <9MSS6_4lYH9acY6W48QdC3ZZdYn2q5OeqsTUY0C7D_c=.de14909a-8309-4247-8da8-843623b2dc67@github.com> Message-ID: On Mon, 1 Feb 2021 23:43:25 GMT, Brent Christian wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > Changes requested by bchristi (Reviewer). (I think my comments may no have been visible because I didn't "submit" my review. Hopefully they are now.) ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From bchristi at openjdk.java.net Mon Feb 1 23:49:45 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Mon, 1 Feb 2021 23:49:45 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v10] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 22:23:02 GMT, Mahendra Chhipa wrote: >> https://bugs.openjdk.java.net/browse/JDK-8183372 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > throwing the specific exceptions. test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 159: > 157: private void match(String actual, String expected) { > 158: System.out.println("actual:" + actual + "expected:" + expected); > 159: assert((actual == null && expected == null) || actual.equals(expected.trim())); I don't think this check is done, because assertions aren't enabled. This should be changed to explicitly throw an exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From mchung at openjdk.java.net Mon Feb 1 23:59:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 1 Feb 2021 23:59:45 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v4] In-Reply-To: <9MSS6_4lYH9acY6W48QdC3ZZdYn2q5OeqsTUY0C7D_c=.de14909a-8309-4247-8da8-843623b2dc67@github.com> References: <9MSS6_4lYH9acY6W48QdC3ZZdYn2q5OeqsTUY0C7D_c=.de14909a-8309-4247-8da8-843623b2dc67@github.com> Message-ID: On Thu, 28 Jan 2021 00:34:08 GMT, Brent Christian wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented the review comments. > > test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 158: > >> 156: private void match(final String actual, final String expected) { >> 157: System.out.println("actual:" + actual + "expected:" + expected); >> 158: assert ((actual == null && expected == null) || actual.equals(expected.trim())); > > I think we need to figure out where the extra space is coming from, if the test worked before, but now fails without adding the `trim()`. > > Also, I think it would be better to throw an exception instead of using `assert`, so the test works with or without assertions being enabled. Good catch. I missed your comment about this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From asemenyuk at openjdk.java.net Tue Feb 2 00:32:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 2 Feb 2021 00:32:41 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 23:41:38 GMT, Alexander Matveev wrote: > We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. All classes from `jdk.jpackage.internal` are accessible in jpackage tests, so there is no need to copy/paste `jdk.jpackage.internal.RetryExecutor`. You can simply import it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2345 From stuart.marks at oracle.com Tue Feb 2 00:37:41 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 1 Feb 2021 16:37:41 -0800 Subject: Why does Set.of disallow duplicate elements? In-Reply-To: References: <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr> <1964605040.2099457.1612128924150.JavaMail.zimbra@u-pem.fr> Message-ID: <5e843c24-04e2-105e-0708-df0f2ee285ac@oracle.com> Indeed it's the case that a varargs method can't determine whether it was called with several explicit arguments or whether it was called with an array. However, that doesn't have any bearing on whether or not Set.of rejects duplicates. The model for Set.of is to support a collection-literal-like syntax where the programmer can write an arbitrary number of elements in the source code for inclusion in the set. Here's an example (though it uses Map.ofEntries instead of Set.of, the same rationale applies): Map tokens = Map.ofEntries( entry("@", AT), entry("|", VERTICAL_BAR), entry("#", HASH), entry("%", PERCENT), entry(":", COLON), entry("^", CARET), entry("&", AMPERSAND), entry("|", EXCLAM), entry("?", QUESTION), entry("$", DOLLAR), entry("::", PAAMAYIM_NEKUDOTAYIM), entry("=", EQUALS), entry(";", SEMICOLON) ); This errors out instead of silently dropping one of the entries. As an optimization, the API provides several fixed-arg overloads of Set.of. With few arguments, the fixed-arg methods are called. If more arguments are added, at a certain point it transparently switches to the varargs form. "Transparently" means that you can't tell (without counting the arguments) whether a fixed-arg or varargs form of Set.of will be called. You don't want the duplicate rejection semantics to change if you add or remove an argument that happens to cross the fixed/varargs threshold. Thus, Set.of rejects duplicates, whether in fixed or varargs form. Set.copyOf(Arrays.asList(...)) is the best way to deduplicate an explicit list of elements into a set. s'marks On 2/1/21 3:01 PM, Aaron Scott-Boddendijk wrote: > Dave, > > || Dave said... > || Okay, I understand this reasoning, but when you want to construct a Set > from an array, you might be tempted to use Set.of(...) because it looks > like it supports an > || array and indeed, you can do Set.of(new int[] {1, 2 }) I believe? > || > || Maybe this is just a quirk because of how varargs work. > > | R?mi said... > | Set.of(int[]) will call Set.of(E) with E being an int[]. > | but > | Set.of(new Integer[] { ... }) calls Set.of(...). > | > | Yes, exactly, it's a known issue with varargs, you have no way to say, i > don't want this varargs to be called with an array. > > I think the confusion is the interaction of boxing and varargs. > >> List list = List.of(1, 2); > > is actually, once auto-boxing is applied by the compiler, executed as... > >> List list = List.of(Integer.valueOf(1), Integer.valueOf(2)); > > So the equivalent explicit array form should use `Integer[]` not `int[]`... > >> Integer[] numbers = new Integer[] {1, 2}; >> List list = List.of(numbers); > > Interestingly, if you actually wanted a `List` you would then > need to say > >> Integer[] numbers = new Integer[] {1, 2}; >> List list = List.of(numbers); > > Which is explicitly telling the compiler what the type arguments are for > this invocation of the generic method 'of'' (rather than allowing it to use > type-inference) > > Regarding the use of `Set.copyOf(Arrays.asList(...))`. I do wonder about > improving the ceremony (because I agree that we want an obvious way of > getting immutable Sets from non-unique inputs) by following the pattern > presented in Optional (`Optional.of` and `Optional.ofNullable`) and > providing `Set.of` and `Set.ofMaybeUnique` (better name needed - > 'ofOptionallyUnique'?) - to which the implementation could just be > `Set.copyOf(Arrays.asList(args))` (unless a more efficient path proves > valuable). > > `Arrays.asList(...array...)` is not all that expensive. It is _not_ an > ArrayList but a much simpler type with rather trivial implementations for > most methods (and 'always throws' implementations for methods that are > unsupported). So not only does it mean that there's no copying occuring to > make the list but it's even possible that JIT manages enough specialisation > and inlining to elide the allocation entirely (though in practice this > doesn't occur as often as we might like). > > -- > Aaron Scott-Boddendijk > > On Mon, Feb 1, 2021 at 10:35 AM wrote: > >> >> >> >> >> >> De: "dfranken jdk" >> ?: "Remi Forax" >> Cc: "core-libs-dev" >> Envoy?: Dimanche 31 Janvier 2021 13:54:44 >> Objet: Re: Why does Set.of disallow duplicate elements? >> >> >> >> >> BQ_BEGIN >> >> Okay, I understand this reasoning, but when you want to construct a Set >> from an array, you might be tempted to use Set.of(...) because it looks >> like it supports an array and indeed, you can do Set.of(new int[] {1, 2 }) >> I believe? >> >> BQ_END >> >> Set.of(int[]) will call Set.of(E) with E being an int[]. >> but >> Set.of(new Integer[] { ... }) calls Set.of(...). >> >> >> BQ_BEGIN >> >> >> Maybe this is just a quirk because of how varargs work. >> >> BQ_END >> >> Yes, exactly, it's a known issue with varargs, you have no way to say, i >> don't want this varargs to be called with an array. >> >> >> BQ_BEGIN >> >> >> I wondered if there was a canonical way to create a Set from an array, but >> couldn't find it, maybe I am missing something? >> I did notice Arrays.asList exists (which makes sense because it creates an >> ArrayList backed by the array), but not Arrays.asSet. >> >> BQ_END >> >> asList() reuse the same backing array, you can not do that with asSet() or >> contains() will be in O(n) in the worst case. >> >> >> BQ_BEGIN >> >> >> So the way I would create a Set from an array would be either >> Arrays.stream(myArr).collect(Collectors.toUnmodifiableSet()) or new >> HashSet<>(Arrays.asList(myArray)) or Set.copyOf(Arrays.asList(myArray)). >> >> BQ_END >> >> yes, the last one is the easy way to create an unmodifiable set from an >> array. >> >> >> BQ_BEGIN >> >> >> I'm not saying the way it is currently implemented is wrong, it's just >> something which can suprise developers as it surprised me. :) >> >> BQ_END >> >> Arrays are currently second class citizen in Java, because they are always >> modifiable and always covariant (String[] can be seen as a Object[]). >> We have talked several times to introduce new variants of arrays, >> non-modifiable one, non-covariant one, etc under the name Array 2.0, but >> Valhalla generics is a blocker for that project. >> Once Valhalla is done, it may be a follow up. >> >> >> BQ_BEGIN >> >> >> Kind regards, >> >> Dave >> >> BQ_END >> >> >> regards, >> R?mi >> >> >> BQ_BEGIN >> >> >> >> Op za 30 jan. 2021 om 21:30 schreef Remi Forax < [ mailto: >> forax at univ-mlv.fr | forax at univ-mlv.fr ] >: >> >> BQ_BEGIN >> Set.of() is the closest way we've got to a literal Set without having >> introduced a special syntax for that in the language. >> >> The idea is that if you conceptually want to write >> Set set = { "hello", "world" }; >> instead, you write >> Set set = Set.of("hello", "world"); >> >> In that context, it makes sense to reject Set constructed with the same >> element twice because this is usually a programming error. >> So >> Set.of("hello", "hello") >> throws an IAE. >> >> If you want a Set from a collection of elements, you can use >> Set.copyOf(List.of("hello", "hello")) >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "dfranken jdk" < [ mailto:dfranken.jdk at gmail.com | >> dfranken.jdk at gmail.com ] > >>> ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net | >> core-libs-dev at openjdk.java.net ] > >>> Envoy?: Samedi 30 Janvier 2021 19:30:06 >>> Objet: Why does Set.of disallow duplicate elements? >> >>> Dear users, >>> >>> While looking at the implementation of Set.of(...) I noticed that >>> duplicate elements are not allowed, e.g. Set.of(1, 1) will throw an >>> IllegalArgumentException. Why has it been decided to do this? >>> >>> My expectation was that duplicates would simply be removed. >>> >>> If I do for instance new HashSet<>() >>> it works and duplicates are removed. To me, it looks a bit inconsistent >>> to have duplicates removed for a collection passed in the constructor, >>> but not for a collection (even though it is a vararg array) passed to a >>> static factory method. >>> >>> Kind regards, >>> >>> Dave Franken >> >> BQ_END >> >> >> BQ_END >> >> >> From smarks at openjdk.java.net Tue Feb 2 01:11:42 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 2 Feb 2021 01:11:42 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == [v5] In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 01:58:02 GMT, Joe Darcy wrote: >> Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. >> >> Once the wording is worked out, I'll replicate it for the analogous methods on Float. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos noticed by @bplb. I did another full reread. Everything looks good! ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1699 From martin at openjdk.java.net Tue Feb 2 01:16:07 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 01:16:07 GMT Subject: RFR: 8259074: regex benchmarks and tests [v3] In-Reply-To: References: Message-ID: > 8259074: regex benchmarks and tests Martin Buchholz has updated the pull request incrementally with two additional commits since the last revision: - refactor correctness checking as suggested by @shipilev - prune @Param values as suggested by Claes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1940/files - new: https://git.openjdk.java.net/jdk/pull/1940/files/abb6c672..5faba5e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=01-02 Stats: 89 lines in 3 files changed: 44 ins; 25 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940 PR: https://git.openjdk.java.net/jdk/pull/1940 From martin at openjdk.java.net Tue Feb 2 01:16:07 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 01:16:07 GMT Subject: RFR: 8259074: regex benchmarks and tests [v2] In-Reply-To: References: <6PsLwBq14fzr95q7JsFcpZzACniQ7cB6OZ6cZZqwN8M=.e4545830-0777-45e9-8a61-0b29b51c60d9@github.com> Message-ID: On Mon, 1 Feb 2021 00:23:56 GMT, Martin Buchholz wrote: >> test/micro/org/openjdk/bench/java/util/regex/Trim.java line 119: >> >>> 117: assert ! lookBehind_find(); >>> 118: assert ! find_loop_two_matchers(); >>> 119: assert ! find_loop_usePattern(); >> >> At a risk of muddling the profiles a bit, this can be rewritten as: >> >> if (!simple_find()) throw new IllegalStateException("simple_find is incorrect"); >> ... > > Thanks Aleksey. But I was hoping for something more magical. > > We really want the checking of the result of the benchmark method to be co-located in the source code with the method, but with zero disturbance to the benchmark numbers. Is such magic possible? I refactored the correctness checking, no longer using the assert facility. ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From martin at openjdk.java.net Tue Feb 2 01:42:40 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 01:42:40 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 20:52:12 GMT, Martin Buchholz wrote: >> The assertion discussion aside, the micros look fine to me. >> >> With an eye towards reducing total run time I'd ask you to consider if all parameter combinations are useful or if we can get the same value after some pruning. > > @cl4es I agree pruning is a good idea. I settled on 3 data points with 16x separations as good enough to clearly show the difference between O(1) O(N) O(N^2) and O(2^N) (although O(2^N) would "run forever"). > > (although ... please tell me you're not actually running these benchmarks in an automated fashion ... too expensive, and needs a human to interpret the results) > A manual exploration of a new set of micros would naturally start with > the default config, so if such a config runs forever, that would be poor > ergonomics IMHO. I don't think such configurations should be checked in > in an active state. We're actually in agreement. There's no actual O(2^N) operation here, and jmh is similar to jtreg in having timeouts indicating failure. Although I've been using shell loops as included in the class comments, I'll make sure running the tests using all the defaults gives sensible results. I'm surprised to see jmh use the same number (5) of warmup and measurement iterations. Unless you're looking for very small effects, one warmup run should be sufficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From jpai at openjdk.java.net Tue Feb 2 02:27:40 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 2 Feb 2021 02:27:40 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> Message-ID: <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> On Mon, 1 Feb 2021 19:21:23 GMT, Brian Burkhalter wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? >> >> As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. >> >> Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. >> >> Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. >> >> Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. >> >> Given the nature of this issue, I haven't added any jtreg test for this change. > > The code change looks all right. It would be better if there were a test, but apparently this might depend on the user who runs the test not having registry access rights. Hello Brian, Thank you for the review. > It would be better if there were a test, but apparently this might depend on the user who runs the test not having registry access rights. That's correct. Looking at the code, it looks to me that this will require very specific setup of the Windows system to be able to trigger the error. > The code change looks all right. Should I go ahead and integrate this? ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From darcy at openjdk.java.net Tue Feb 2 02:32:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 2 Feb 2021 02:32:08 GMT Subject: RFR: JDK-8257086: Clarify differences between {Float, Double}.equals and == [v6] In-Reply-To: References: Message-ID: > Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. > > Once the wording is worked out, I'll replicate it for the analogous methods on Float. 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 10 additional commits since the last revision: - Fix type in URL in Float.java. - Merge branch 'master' into JDK-8257086 - Fix typos noticed by @bplb. - Editing pass on changes in Double; add accommodations in Float. - Merge branch 'master' into JDK-8257086 - Update reworked wording from @smarks. - Merge branch 'master' into JDK-8257086 - Merge branch 'master' into JDK-8257086 - Fix whitespace - Initial work for JDK-8257086. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1699/files - new: https://git.openjdk.java.net/jdk/pull/1699/files/b419ca79..7c977bd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1699&range=04-05 Stats: 1658 lines in 43 files changed: 728 ins; 760 del; 170 mod Patch: https://git.openjdk.java.net/jdk/pull/1699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1699/head:pull/1699 PR: https://git.openjdk.java.net/jdk/pull/1699 From jpai at openjdk.java.net Tue Feb 2 02:33:41 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 2 Feb 2021 02:33:41 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Tue, 2 Feb 2021 02:25:04 GMT, Jaikiran Pai wrote: > > The code change looks all right. > > Should I go ahead and integrate this? Actually, I didn't notice that this PR wasn't marked as reviewed. I'll wait for the review(s) then. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From darcy at openjdk.java.net Tue Feb 2 02:36:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 2 Feb 2021 02:36:41 GMT Subject: Integrated: JDK-8257086: Clarify differences between {Float, Double}.equals and == In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:29:49 GMT, Joe Darcy wrote: > Updates to the specifications of Double.{equals, compareTo} to explain more explicitly why the obvious wrappers around "==" and "<"/"==" are not sufficient for floating-point values. > > Once the wording is worked out, I'll replicate it for the analogous methods on Float. This pull request has now been integrated. Changeset: 474dba2d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/474dba2d Stats: 205 lines in 2 files changed: 124 ins; 31 del; 50 mod 8257086: Clarify differences between {Float, Double}.equals and == Reviewed-by: smarks, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/1699 From bpb at openjdk.java.net Tue Feb 2 02:43:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Feb 2021 02:43:57 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Tue, 2 Feb 2021 02:31:09 GMT, Jaikiran Pai wrote: >> Hello Brian, >> >> Thank you for the review. >> >>> It would be better if there were a test, but apparently this might depend on the user who runs the test not having registry access rights. >> >> That's correct. Looking at the code, it looks to me that this will require very specific setup of the Windows system to be able to trigger the error. >> >>> The code change looks all right. >> >> Should I go ahead and integrate this? > >> > The code change looks all right. >> >> Should I go ahead and integrate this? > > Actually, I didn't notice that this PR wasn't marked as reviewed. I'll wait for the review(s) then. I'd let it sit for a bit in case others want to comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From martin at openjdk.java.net Tue Feb 2 02:59:09 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 02:59:09 GMT Subject: RFR: 8259074: regex benchmarks and tests [v4] In-Reply-To: References: Message-ID: > 8259074: regex benchmarks and tests Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision: add annotations for sensible defaults ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1940/files - new: https://git.openjdk.java.net/jdk/pull/1940/files/5faba5e7..89638833 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=02-03 Stats: 15 lines in 4 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940 PR: https://git.openjdk.java.net/jdk/pull/1940 From martin at openjdk.java.net Tue Feb 2 03:01:45 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 03:01:45 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 01:40:09 GMT, Martin Buchholz wrote: >> @cl4es I agree pruning is a good idea. I settled on 3 data points with 16x separations as good enough to clearly show the difference between O(1) O(N) O(N^2) and O(2^N) (although O(2^N) would "run forever"). >> >> (although ... please tell me you're not actually running these benchmarks in an automated fashion ... too expensive, and needs a human to interpret the results) > >> A manual exploration of a new set of micros would naturally start with >> the default config, so if such a config runs forever, that would be poor >> ergonomics IMHO. I don't think such configurations should be checked in >> in an active state. > > We're actually in agreement. There's no actual O(2^N) operation here, and jmh is similar to jtreg in having timeouts indicating failure. > > Although I've been using shell loops as included in the class comments, I'll make sure running the tests using all the defaults gives sensible results. > > I'm surprised to see jmh use the same number (5) of warmup and measurement iterations. Unless you're looking for very small effects, one warmup run should be sufficient. I added annotations for sensible (faster) default, including @Warmup(iterations = 1) ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From martin at openjdk.java.net Tue Feb 2 03:07:08 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Tue, 2 Feb 2021 03:07:08 GMT Subject: RFR: 8259074: regex benchmarks and tests [v5] In-Reply-To: References: Message-ID: > 8259074: regex benchmarks and tests Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision: fix imports ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1940/files - new: https://git.openjdk.java.net/jdk/pull/1940/files/89638833..2f688a41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1940&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1940/head:pull/1940 PR: https://git.openjdk.java.net/jdk/pull/1940 From almatvee at openjdk.java.net Tue Feb 2 03:59:00 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 2 Feb 2021 03:59:00 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' [v2] In-Reply-To: References: Message-ID: > We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject disk2 - Resource busy' [v2] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2345/files - new: https://git.openjdk.java.net/jdk/pull/2345/files/36021a22..5ffde267 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2345&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2345&range=00-01 Stats: 108 lines in 3 files changed: 1 ins; 98 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2345/head:pull/2345 PR: https://git.openjdk.java.net/jdk/pull/2345 From almatvee at openjdk.java.net Tue Feb 2 04:02:40 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 2 Feb 2021 04:02:40 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 00:29:39 GMT, Alexey Semenyuk wrote: >> We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. > > All classes from `jdk.jpackage.internal` are accessible in jpackage tests, so there is no need to copy/paste `jdk.jpackage.internal.RetryExecutor`. You can simply import it. I removed RetryExecutor.java and jdk.jpackage.internal.RetryExecutor will be used instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/2345 From dfranken.jdk at gmail.com Tue Feb 2 07:43:12 2021 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Tue, 02 Feb 2021 08:43:12 +0100 Subject: Why does Set.of disallow duplicate elements? In-Reply-To: <5e843c24-04e2-105e-0708-df0f2ee285ac@oracle.com> References: <2099264599.1848135.1612038604962.JavaMail.zimbra@u-pem.fr> <1964605040.2099457.1612128924150.JavaMail.zimbra@u-pem.fr> <5e843c24-04e2-105e-0708-df0f2ee285ac@oracle.com> Message-ID: <71fac4d2730e69900dd91773507900fa8d9f8af6.camel@gmail.com> Okay, so to summarize this discussion a bit: Set.of is, like its counterpart Map.ofEntries, only to be used with explicit varargs, not an array which happens to be accepted as a varargs parameter, this would only confuse things. And if it is called with varargs, the intention is to catch programming errors at runtime by throwing an exception on duplicates instead of silently ignoring them. If we were to silently allow duplicates in Set.of you would run into the situation where the number of varargs passed would not match the size of the Set and this may also be surprising. Yet we already have the understanding that Sets eliminate duplicates so this might not be that big of an issue. I do like the proposal of having a canonical way to turn an array into a Set though, but that might be a discussion for another time and maybe it will be better suited if the arrays themselves are somehow improved. Thanks for your input, Dave On Mon, 2021-02-01 at 16:37 -0800, Stuart Marks wrote: > Indeed it's the case that a varargs method can't determine whether it > was called > with several explicit arguments or whether it was called with an > array. However, > that doesn't have any bearing on whether or not Set.of rejects > duplicates. > > The model for Set.of is to support a collection-literal-like syntax > where the > programmer can write an arbitrary number of elements in the source > code for > inclusion in the set. Here's an example (though it uses Map.ofEntries > instead of > Set.of, the same rationale applies): > > > Map tokens = Map.ofEntries( > ???? entry("@",???? AT), > ???? entry("|",???? VERTICAL_BAR), > ???? entry("#",???? HASH), > ???? entry("%",???? PERCENT), > ???? entry(":",???? COLON), > ???? entry("^",???? CARET), > ???? entry("&",???? AMPERSAND), > ???? entry("|",???? EXCLAM), > ???? entry("?",???? QUESTION), > ???? entry("$",???? DOLLAR), > ???? entry("::",??? PAAMAYIM_NEKUDOTAYIM), > ???? entry("=",???? EQUALS), > ???? entry(";",???? SEMICOLON) > ); > > > This errors out instead of silently dropping one of the entries. > > As an optimization, the API provides several fixed-arg overloads of > Set.of. With few > arguments, the fixed-arg methods are called. If more arguments are > added, at a > certain point it transparently switches to the varargs form. > "Transparently" means > that you can't tell (without counting the arguments) whether a fixed- > arg or varargs > form of Set.of will be called. You don't want the duplicate rejection > semantics to > change if you add or remove an argument that happens to cross the > fixed/varargs > threshold. Thus, Set.of rejects duplicates, whether in fixed or > varargs form. > > Set.copyOf(Arrays.asList(...)) is the best way to deduplicate an > explicit list of > elements into a set. > > s'marks > > > > > On 2/1/21 3:01 PM, Aaron Scott-Boddendijk wrote: > > ? Dave, > > > > > > Dave said... > > > > Okay, I understand this reasoning, but when you want to > > > > construct a Set > > from an array, you might be tempted to use Set.of(...) because it > > looks > > like it supports an > > > > array and indeed, you can do Set.of(new int[] {1, 2 }) I > > > > believe? > > > > > > > > Maybe this is just a quirk because of how varargs work. > > > > > R?mi said... > > > Set.of(int[]) will call Set.of(E) with E being an int[]. > > > but > > > Set.of(new Integer[] { ... }) calls Set.of(...). > > > > > > Yes, exactly, it's a known issue with varargs, you have no way to > > > say, i > > don't want this varargs to be called with an array. > > > > I think the confusion is the interaction of boxing and varargs. > > > > > List list = List.of(1, 2); > > > > is actually, once auto-boxing is applied by the compiler, executed > > as... > > > > > List list = List.of(Integer.valueOf(1), > > > Integer.valueOf(2)); > > > > So the equivalent explicit array form should use `Integer[]` not > > `int[]`... > > > > > Integer[] numbers = new Integer[] {1, 2}; > > > List list = List.of(numbers); > > > > Interestingly, if you actually wanted a `List` you would > > then > > need to say > > > > > Integer[] numbers = new Integer[] {1, 2}; > > > List list = List.of(numbers); > > > > Which is explicitly telling the compiler what the type arguments > > are for > > this invocation of the generic method 'of'' (rather than allowing > > it to use > > type-inference) > > > > Regarding the use of `Set.copyOf(Arrays.asList(...))`. I do wonder > > about > > improving the ceremony (because I agree that we want an obvious way > > of > > getting immutable Sets from non-unique inputs) by following the > > pattern > > presented in Optional (`Optional.of` and `Optional.ofNullable`) and > > providing `Set.of` and `Set.ofMaybeUnique` (better name needed - > > 'ofOptionallyUnique'?) - to which the implementation could just be > > `Set.copyOf(Arrays.asList(args))` (unless a more efficient path > > proves > > valuable). > > > > `Arrays.asList(...array...)` is not all that expensive. It is _not_ > > an > > ArrayList but a much simpler type with rather trivial > > implementations for > > most methods (and 'always throws' implementations for methods that > > are > > unsupported). So not only does it mean that there's no copying > > occuring to > > make the list but it's even possible that JIT manages enough > > specialisation > > and inlining to elide the allocation entirely (though in practice > > this > > doesn't occur as often as we might like). > > > > -- > > Aaron Scott-Boddendijk > > > > On Mon, Feb 1, 2021 at 10:35 AM wrote: > > > > > > > > > > > > > > > > > > > > De: "dfranken jdk" > > > ?: "Remi Forax" > > > Cc: "core-libs-dev" > > > Envoy?: Dimanche 31 Janvier 2021 13:54:44 > > > Objet: Re: Why does Set.of disallow duplicate elements? > > > > > > > > > > > > > > > BQ_BEGIN > > > > > > Okay, I understand this reasoning, but when you want to construct > > > a Set > > > from an array, you might be tempted to use Set.of(...) because it > > > looks > > > like it supports an array and indeed, you can do Set.of(new int[] > > > {1, 2 }) > > > I believe? > > > > > > BQ_END > > > > > > Set.of(int[]) will call Set.of(E) with E being an int[]. > > > but > > > Set.of(new Integer[] { ... }) calls Set.of(...). > > > > > > > > > BQ_BEGIN > > > > > > > > > Maybe this is just a quirk because of how varargs work. > > > > > > BQ_END > > > > > > Yes, exactly, it's a known issue with varargs, you have no way to > > > say, i > > > don't want this varargs to be called with an array. > > > > > > > > > BQ_BEGIN > > > > > > > > > I wondered if there was a canonical way to create a Set from an > > > array, but > > > couldn't find it, maybe I am missing something? > > > I did notice Arrays.asList exists (which makes sense because it > > > creates an > > > ArrayList backed by the array), but not Arrays.asSet. > > > > > > BQ_END > > > > > > asList() reuse the same backing array, you can not do that with > > > asSet() or > > > contains() will be in O(n) in the worst case. > > > > > > > > > BQ_BEGIN > > > > > > > > > So the way I would create a Set from an array would be either > > > Arrays.stream(myArr).collect(Collectors.toUnmodifiableSet()) or > > > new > > > HashSet<>(Arrays.asList(myArray)) or > > > Set.copyOf(Arrays.asList(myArray)). > > > > > > BQ_END > > > > > > yes, the last one is the easy way to create an unmodifiable set > > > from an > > > array. > > > > > > > > > BQ_BEGIN > > > > > > > > > I'm not saying the way it is currently implemented is wrong, it's > > > just > > > something which can suprise developers as it surprised me. :) > > > > > > BQ_END > > > > > > Arrays are currently second class citizen in Java, because they > > > are always > > > modifiable and always covariant (String[] can be seen as a > > > Object[]). > > > We have talked several times to introduce new variants of arrays, > > > non-modifiable one, non-covariant one, etc under the name Array > > > 2.0, but > > > Valhalla generics is a blocker for that project. > > > Once Valhalla is done, it may be a follow up. > > > > > > > > > BQ_BEGIN > > > > > > > > > Kind regards, > > > > > > Dave > > > > > > BQ_END > > > > > > > > > regards, > > > R?mi > > > > > > > > > BQ_BEGIN > > > > > > > > > > > > Op za 30 jan. 2021 om 21:30 schreef Remi Forax < [ mailto: > > > forax at univ-mlv.fr?| forax at univ-mlv.fr?] >: > > > > > > BQ_BEGIN > > > Set.of() is the closest way we've got to a literal Set without > > > having > > > introduced a special syntax for that in the language. > > > > > > The idea is that if you conceptually want to write > > > Set set = { "hello", "world" }; > > > instead, you write > > > Set set = Set.of("hello", "world"); > > > > > > In that context, it makes sense to reject Set constructed with > > > the same > > > element twice because this is usually a programming error. > > > So > > > Set.of("hello", "hello") > > > throws an IAE. > > > > > > If you want a Set from a collection of elements, you can use > > > Set.copyOf(List.of("hello", "hello")) > > > > > > regards, > > > R?mi > > > > > > ----- Mail original ----- > > > > De: "dfranken jdk" < [ mailto:dfranken.jdk at gmail.com?| > > > dfranken.jdk at gmail.com?] > > > > > ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net?| > > > core-libs-dev at openjdk.java.net?] > > > > > Envoy?: Samedi 30 Janvier 2021 19:30:06 > > > > Objet: Why does Set.of disallow duplicate elements? > > > > > > > Dear users, > > > > > > > > While looking at the implementation of Set.of(...) I noticed > > > > that > > > > duplicate elements are not allowed, e.g. Set.of(1, 1) will > > > > throw an > > > > IllegalArgumentException. Why has it been decided to do this? > > > > > > > > My expectation was that duplicates would simply be removed. > > > > > > > > If I do for instance new HashSet<>( > > > duplicates>) > > > > it works and duplicates are removed. To me, it looks a bit > > > > inconsistent > > > > to have duplicates removed for a collection passed in the > > > > constructor, > > > > but not for a collection (even though it is a vararg array) > > > > passed to a > > > > static factory method. > > > > > > > > Kind regards, > > > > > > > > Dave Franken > > > > > > BQ_END > > > > > > > > > BQ_END > > > > > > > > > From ihse at openjdk.java.net Tue Feb 2 07:44:46 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 2 Feb 2021 07:44:46 GMT Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16 In-Reply-To: <_IdMSe0Y15bWzd3cgSv1-izf-0qxvEguB_NOhviVkSs=.7e14f316-a590-44a6-8b9e-fb1cb92331e4@github.com> References: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> <_IdMSe0Y15bWzd3cgSv1-izf-0qxvEguB_NOhviVkSs=.7e14f316-a590-44a6-8b9e-fb1cb92331e4@github.com> Message-ID: <3a0E-k8Lrvt-asm4VVePHkxTyYqsWO2aNYWOv-TgFXo=.e5a05a5b-6dd2-4ec8-8654-8a26f4f3f451@github.com> On Mon, 1 Feb 2021 22:46:15 GMT, David Holmes wrote: >> Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. > > Thanks for doing this Magnus! I had overlooked the fact we would need to re-run this in 2021 regardless of whether there were any content changes to propagate. > > Cheers, > David @dholmes-ora I did not think of that myself either. But the make target did the Right Thing. :-) ------------- PR: https://git.openjdk.java.net/jdk16/pull/142 From ihse at openjdk.java.net Tue Feb 2 07:44:47 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 2 Feb 2021 07:44:47 GMT Subject: [jdk16] Integrated: 8258378: Final nroff manpage update for JDK 16 In-Reply-To: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> References: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com> Message-ID: On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote: > Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. This pull request has now been integrated. Changeset: ed1a7755 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk16/commit/ed1a7755 Stats: 238 lines in 27 files changed: 98 ins; 111 del; 29 mod 8258378: Final nroff manpage update for JDK 16 Reviewed-by: erikj, dholmes ------------- PR: https://git.openjdk.java.net/jdk16/pull/142 From Alan.Bateman at oracle.com Tue Feb 2 07:46:41 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Feb 2021 07:46:41 +0000 Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: Message-ID: <6c4940de-b7ec-e13d-1d35-87f28ff0c7bc@oracle.com> On 01/02/2021 22:13, Daniel D.Daugherty wrote: > A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the > ProblemList. It was removed in error (see the bug for the details). > Something fishy here, Sundar ran the test 500 times on the 3 main platforms before integrating. I asked him to do this because of reliability issues with some of the jlink tests. linux-aarch64 was missed in that testing and we do seem to have an issue there at least. -Alan From ihse at openjdk.java.net Tue Feb 2 08:17:51 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 2 Feb 2021 08:17:51 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> Message-ID: <9Blq7Y4KR8iZy6lazmOmdoY74SldevY4pir1anU9VM0=.6854695d-9dbb-4a31-9367-1a21369d61e6@github.com> On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote: >> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. >> - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed macos build "Build" change looks good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2338 From redestad at openjdk.java.net Tue Feb 2 09:45:51 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 09:45:51 GMT Subject: RFR: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 02:58:30 GMT, Martin Buchholz wrote: >>> A manual exploration of a new set of micros would naturally start with >>> the default config, so if such a config runs forever, that would be poor >>> ergonomics IMHO. I don't think such configurations should be checked in >>> in an active state. >> >> We're actually in agreement. There's no actual O(2^N) operation here, and jmh is similar to jtreg in having timeouts indicating failure. >> >> Although I've been using shell loops as included in the class comments, I'll make sure running the tests using all the defaults gives sensible results. >> >> I'm surprised to see jmh use the same number (5) of warmup and measurement iterations. Unless you're looking for very small effects, one warmup run should be sufficient. > > I added annotations for sensible (faster) default, including @Warmup(iterations = 1) > I added annotations for sensible (faster) default, including `@WarmUp(iterations = 1)` Perhaps just a personal preference.. if you instead tune down time per iteration (` @Warmup(iterations = 5, time = 2)`) you would get the same warmup time budget but also some immediate feedback that the code is stabilizing well before switching over to measurement iterations. ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From Alan.Bateman at oracle.com Tue Feb 2 10:07:38 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Feb 2021 10:07:38 +0000 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <633dd29b-71e7-8212-e98c-b577f5733394@j-kuhn.de> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> <1915323937.509806.1612191512611.JavaMail.zimbra@u-pem.fr> <633dd29b-71e7-8212-e98c-b577f5733394@j-kuhn.de> Message-ID: On 01/02/2021 15:19, Johannes Kuhn wrote: > : > > Thanks R?mi. > > The problem here is that (according to Peter Levart tests), the cold > use of a MHMethodAccessor is 11x as expensive as using the native > accessor. > > In some way, it sill makes sense to keep the native accessor around, > at least during startup. On the other hand, I heard that there have > been some improvements on the AppCDS w.r.t MethodHandles, but I'm out > of the loop there. > > An other problem with completely replacing the native accessors is > some bootstrap problem - if certain flags are set (some of them are > used to build the CDS), then the java.lang.invoke infrastructure tries > to write stuff to System.out. But to initialize System.out, the > charset has to be constructed, which relies on reflection. > > I can see some potential in improving the initialization of the > standard charset, but it's out of the scope here. > > Apropos scope: I try to narrow the scope down to "replace > MethodAccessorGenerator with accessors that delegate to MethodHandles". > Once this is done, then additional improvements can be made - > including some that take loom into account. Or adding some > @Stable/@ForceInline stuff so the JIT can better optimize reflective > calls. > > But currently (didn't look into the loom source) there are only two > strategies: Native accessor (bad for loom) or generated (bytecode > spinning, doesn't work with hidden classes). So, with loom and hidden > classes you get the worst of both worlds. MethodHandles solve that. As things stands, virtual threads don't call through the VM because of the potential for blocking with a native trampoline frame on the stack. The bytecode generator is still used for @CS methods but otherwise it uses method handles. Hidden classes should be okay although we don't have tests for that yet. In any case, this will all be replaced once Mandy's work is further along. Core reflection usages during initPhase2 can be dealt it by deferral until the module system is fully initialized (as Mandy suggests) as using invoke count would be too fragile. For @CS methods you will see linked issues where the suggestion to link to an overloaded method that takes the caller class has been suggested. I also suspect there will be some C2 work needed. -Alan From redestad at openjdk.java.net Tue Feb 2 10:40:02 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 10:40:02 GMT Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v3] In-Reply-To: References: Message-ID: On Sun, 31 Jan 2021 18:05:30 GMT, Lance Andersen wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify comments, put normal path branch first in UTF8 checkedHash > > Hi Claes > > I gone through your changes a couple of times and with your latest updates, the patch looks good. We should probably consider looking at Zip FS as its initCEN is similar at a future time. > > Thank you for your efforts to optimize the performance in this area. Added some comments and refactored slightly after offline feedback from Eirik. ------------- PR: https://git.openjdk.java.net/jdk/pull/2306 From redestad at openjdk.java.net Tue Feb 2 10:40:01 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 10:40:01 GMT Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v4] In-Reply-To: References: Message-ID: <51Vs9v8X6Z2tq0pXjPEY1ey5CsYc6IBg4Dc_qBtcaW0=.2c8019f3-dd0c-495a-9179-9ad3169c576f@github.com> > - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward. > - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on > > Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code. > > Testing: tier1-4 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Refactor out specific ZipException from checkedHash ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2306/files - new: https://git.openjdk.java.net/jdk/pull/2306/files/bb1659e3..695273fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2306&range=02-03 Stats: 75 lines in 2 files changed: 18 ins; 14 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/2306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2306/head:pull/2306 PR: https://git.openjdk.java.net/jdk/pull/2306 From info at j-kuhn.de Tue Feb 2 10:52:12 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 2 Feb 2021 11:52:12 +0100 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> <1915323937.509806.1612191512611.JavaMail.zimbra@u-pem.fr> <633dd29b-71e7-8212-e98c-b577f5733394@j-kuhn.de> Message-ID: <8f9deea9-54d1-4e2d-4dd7-9f0d72f276a7@j-kuhn.de> Thanks Alan. For using MethodHandles and @CS methods: As far as I remember, MethodHandle is also skipped on a stack walk for security. In my prototype (where I did always use MethodHandles for Method.invoke) MethodHandles.class.findStatic("lookup").invoke(null) did return a Lookup with the right lookup class. So, MethodHandles as implementation works - if all classes on the stack extend MethodAccessorImpl or MethodHandle. I did a prototype in the past to use an overload for @CS methods [1] While C2 could link to the overload directly, this is not needed in my prototype. The roadblock I hit was that Method.invoke is itself @CS, so either the Method.invoke overload will have to inject a frame for the caller or all @CS methods need to have their overload. (And the overload for Method.invoke needs it's own intrinsic, so it's skipped during security stack walk.) The other problem with regard to @CS is Thread.getContextClassLoader(). This method can be virtually called. But a private overload would bypass the any override. Currently, java.lang.invoke will bind the caller if the called method is named "getContextClassLoader" and the method is in an interface. Things get interesting if you consider this interface: interface GetCCLObject {Object getContextClassLoader();} javac will now add a bridge method if you extend Thread and implement this interface - which calls the @CS method. And that class is now the caller. Not exactly sure what my conclusion is, but I tend to "if you implement such an interface, you are out of luck". (That's the point my head starts to hurt.) In the end - Loom has an other implementation of JDK-6824466. Makes 4. Interesting is that they all have been born out of different requirements - so it seems indeed to be a good idea. In my prototype I did fell into the trap that I tried too much at once. And @CS is a really complex topic that might be attractive to somehow squeeze into JDK-6824466. But I'm not convinced that this is a good idea. - Johannes [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html On 02-Feb-21 11:07, Alan Bateman wrote: > On 01/02/2021 15:19, Johannes Kuhn wrote: >> : >> >> Thanks R?mi. >> >> The problem here is that (according to Peter Levart tests), the cold >> use of a MHMethodAccessor is 11x as expensive as using the native >> accessor. >> >> In some way, it sill makes sense to keep the native accessor around, >> at least during startup. On the other hand, I heard that there have >> been some improvements on the AppCDS w.r.t MethodHandles, but I'm out >> of the loop there. >> >> An other problem with completely replacing the native accessors is >> some bootstrap problem - if certain flags are set (some of them are >> used to build the CDS), then the java.lang.invoke infrastructure tries >> to write stuff to System.out. But to initialize System.out, the >> charset has to be constructed, which relies on reflection. >> >> I can see some potential in improving the initialization of the >> standard charset, but it's out of the scope here. >> >> Apropos scope: I try to narrow the scope down to "replace >> MethodAccessorGenerator with accessors that delegate to MethodHandles". >> Once this is done, then additional improvements can be made - >> including some that take loom into account. Or adding some >> @Stable/@ForceInline stuff so the JIT can better optimize reflective >> calls. >> >> But currently (didn't look into the loom source) there are only two >> strategies: Native accessor (bad for loom) or generated (bytecode >> spinning, doesn't work with hidden classes). So, with loom and hidden >> classes you get the worst of both worlds. MethodHandles solve that. > As things stands, virtual threads don't call through the VM because of > the potential for blocking with a native trampoline frame on the stack. > The bytecode generator is still used for @CS methods but otherwise it > uses method handles. Hidden classes should be okay although we don't > have tests for that yet. In any case, this will all be replaced once > Mandy's work is further along. Core reflection usages during initPhase2 > can be dealt it by deferral until the module system is fully initialized > (as Mandy suggests) as using invoke count would be too fragile. For @CS > methods you will see linked issues where the suggestion to link to an > overloaded method that takes the caller class has been suggested. I also > suspect there will be some C2 work needed. > > -Alan From vkempik at openjdk.java.net Tue Feb 2 11:45:04 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 2 Feb 2021 11:45:04 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie wrote: >>> Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) >> >>>support for looking for proper hsdis dylib library was added as part of this jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > >> > Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > >> >> > support for looking for proper hsdis dylib library was added as part of this jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( Sorry I was under impression hsdis is not part of openjdk tree. Alan, could you please share with us the version of binutils you were using in your test ? Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Tue Feb 2 11:59:08 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 2 Feb 2021 11:59:08 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: support macos_aarch64 in hsdis ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b421e0b4..3c705ae5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07-08 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Tue Feb 2 11:59:09 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 2 Feb 2021 11:59:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using in your test ? > > Regards, Vladimir I have updated PR with patch for hsdis, one thing to notice, LP64 is not defined for arm64 in Makefile ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+4146708+a74nh at openjdk.java.net Tue Feb 2 12:17:47 2021 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 2 Feb 2021 12:17:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6] In-Reply-To: References: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com> <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com> Message-ID: On Tue, 2 Feb 2021 11:56:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using in your test ? > I was just using the latest HEAD: git clone git://sourceware.org/git/binutils-gdb.git src/utils/hsdis/build/binutils A slightly safer approach would be to grab the latest release: https://ftp.gnu.org/gnu/binutils/binutils-2.36.tar.gz Once hsdis-demo was working for me, for only other oddity I had was that the library needed renaming when copying/linking into the build dir: jdk/lib/server/libhsdis-aarch64.dylib ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From redestad at openjdk.java.net Tue Feb 2 13:13:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 13:13:44 GMT Subject: RFR: 8259074: regex benchmarks and tests [v5] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 03:07:08 GMT, Martin Buchholz wrote: >> 8259074: regex benchmarks and tests > > Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision: > > fix imports Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From shade at openjdk.java.net Tue Feb 2 13:18:56 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 13:18:56 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings Message-ID: Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" test Insert.insertOffset(): failure java.lang.AssertionError: expected [??abc] but found [efabc] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:496) at org.testng.Assert.assertEquals(Assert.java:125) at org.testng.Assert.assertEquals(Assert.java:178) at org.testng.Assert.assertEquals(Assert.java:188) at Insert.insertOffset(Insert.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). Additional testing: - [x] Linux x86_64 `tier1` default, passes - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) - [x] Linux ARM32, affected test now passes ------------- Commit messages: - 8260927: StringBuilder::insert is incorrect without Compact Strings Changes: https://git.openjdk.java.net/jdk16/pull/143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=143&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260927 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk16/pull/143 From redestad at openjdk.java.net Tue Feb 2 13:25:47 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 13:25:47 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings In-Reply-To: References: Message-ID: <1bkJXS4xNHiB6g4GpCjVD2FnH29Ct7wi8ivjSZV4SAA=.7cd4f31f-70af-4170-b999-097d71c3dcac@github.com> On Tue, 2 Feb 2021 13:12:53 GMT, Aleksey Shipilev wrote: > Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" > > test Insert.insertOffset(): failure > java.lang.AssertionError: expected [??abc] but found [efabc] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at org.testng.Assert.assertEquals(Assert.java:188) > at Insert.insertOffset(Insert.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). > > void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { > if (coder() == coder) { > System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); > } else { // this.coder == LATIN && coder == UTF16 > StringLatin1.inflate(value, srcPos, dst, dstBegin, length); > } > } > > When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. > > Additional testing: > - [x] Linux x86_64 `tier1` default, passes > - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > - [x] Linux ARM32, affected test now passes Looks good, thanks for fixing this. Should we add an explicit run with -CompactStrings to the Insert.java test? That'd have caught this issue sooner - perhaps already by the GA testing. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/143 From shade at openjdk.java.net Tue Feb 2 13:31:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 13:31:58 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: References: Message-ID: > Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" > > test Insert.insertOffset(): failure > java.lang.AssertionError: expected [??abc] but found [efabc] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at org.testng.Assert.assertEquals(Assert.java:188) > at Insert.insertOffset(Insert.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). > > void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { > if (coder() == coder) { > System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); > } else { // this.coder == LATIN && coder == UTF16 > StringLatin1.inflate(value, srcPos, dst, dstBegin, length); > } > } > > When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. > > Additional testing: > - [x] Linux ARM32, affected test now passes > - [x] Linux x86_64, affected test now passes > - [x] Linux x86_64 `tier1` default, passes > - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Add the regression test case ------------- Changes: - all: https://git.openjdk.java.net/jdk16/pull/143/files - new: https://git.openjdk.java.net/jdk16/pull/143/files/e3c4da2b..0aa73e5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=143&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=143&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk16/pull/143 From shade at openjdk.java.net Tue Feb 2 13:31:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 13:31:59 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: <1bkJXS4xNHiB6g4GpCjVD2FnH29Ct7wi8ivjSZV4SAA=.7cd4f31f-70af-4170-b999-097d71c3dcac@github.com> References: <1bkJXS4xNHiB6g4GpCjVD2FnH29Ct7wi8ivjSZV4SAA=.7cd4f31f-70af-4170-b999-097d71c3dcac@github.com> Message-ID: <0D6eMNHkVrluK5bZi5OkiOlG0bh5w2JI6GWCnGSXLzg=.44181f08-87e9-4a58-a565-b9231c53b7d7@github.com> On Tue, 2 Feb 2021 13:23:16 GMT, Claes Redestad wrote: > Should we add an explicit run with -CompactStrings to the Insert.java test? That'd have caught this issue sooner - perhaps already by the GA testing. Yes, I thought about the same. Added and re-checked that it catches the failure. (I also added `-XX:-CompactStrings` jobs to my CI workflows). ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From redestad at openjdk.java.net Tue Feb 2 13:37:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 2 Feb 2021 13:37:46 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 13:31:58 GMT, Aleksey Shipilev wrote: >> Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: >> >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" >> >> test Insert.insertOffset(): failure >> java.lang.AssertionError: expected [??abc] but found [efabc] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:496) >> at org.testng.Assert.assertEquals(Assert.java:125) >> at org.testng.Assert.assertEquals(Assert.java:178) >> at org.testng.Assert.assertEquals(Assert.java:188) >> at Insert.insertOffset(Insert.java:45) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). >> >> void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { >> if (coder() == coder) { >> System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); >> } else { // this.coder == LATIN && coder == UTF16 >> StringLatin1.inflate(value, srcPos, dst, dstBegin, length); >> } >> } >> >> When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. >> >> Additional testing: >> - [x] Linux ARM32, affected test now passes >> - [x] Linux x86_64, affected test now passes >> - [x] Linux x86_64 `tier1` default, passes >> - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add the regression test case Good ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/143 From alanb at openjdk.java.net Tue Feb 2 14:06:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Feb 2021 14:06:46 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 13:31:58 GMT, Aleksey Shipilev wrote: >> Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: >> >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" >> >> test Insert.insertOffset(): failure >> java.lang.AssertionError: expected [??abc] but found [efabc] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:496) >> at org.testng.Assert.assertEquals(Assert.java:125) >> at org.testng.Assert.assertEquals(Assert.java:178) >> at org.testng.Assert.assertEquals(Assert.java:188) >> at Insert.insertOffset(Insert.java:45) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). >> >> void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { >> if (coder() == coder) { >> System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); >> } else { // this.coder == LATIN && coder == UTF16 >> StringLatin1.inflate(value, srcPos, dst, dstBegin, length); >> } >> } >> >> When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. >> >> Additional testing: >> - [x] Linux ARM32, affected test now passes >> - [x] Linux x86_64, affected test now passes >> - [x] Linux x86_64 `tier1` default, passes >> - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add the regression test case Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From daniel.daugherty at oracle.com Tue Feb 2 14:46:21 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 2 Feb 2021 09:46:21 -0500 Subject: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: <6c4940de-b7ec-e13d-1d35-87f28ff0c7bc@oracle.com> References: <6c4940de-b7ec-e13d-1d35-87f28ff0c7bc@oracle.com> Message-ID: On 2/2/21 2:46 AM, Alan Bateman wrote: > On 01/02/2021 22:13, Daniel D.Daugherty wrote: >> A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java >> back on the >> ProblemList. It was removed in error (see the bug for the details). >> > Something fishy here, Sundar ran the test 500 times on the 3 main > platforms before integrating. I asked him to do this because of > reliability issues with some of the jlink tests. linux-aarch64 was > missed in that testing and we do seem to have an issue there at least. > > -Alan I've updated https://bugs.openjdk.java.net/browse/JDK-8247407 with a confidential comment and a link to bring up the recent test failures in the JDK17 CI. The linux-aarch64 failures were pretty constant, the linux-x64 and macOSX failures were intermittent. I think this was a reasonable ProblemListing given the failures that I observed yesterday. Dan From herrick at openjdk.java.net Tue Feb 2 15:07:45 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 2 Feb 2021 15:07:45 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' [v2] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 03:59:00 GMT, Alexander Matveev wrote: >> We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject disk2 - Resource busy' [v2] Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2345 From asemenyuk at openjdk.java.net Tue Feb 2 15:07:47 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 2 Feb 2021 15:07:47 GMT Subject: RFR: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' [v2] In-Reply-To: References: Message-ID: <0NODh9L1AbLMQvU33aRm2c_ev3GeSZ4sR-Z2kmt4ue4=.b76192ff-4ed4-4945-a107-8e4a72a64cb8@github.com> On Tue, 2 Feb 2021 03:59:00 GMT, Alexander Matveev wrote: >> We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject disk2 - Resource busy' [v2] Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2345 From rriggs at openjdk.java.net Tue Feb 2 15:16:43 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 2 Feb 2021 15:16:43 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 13:31:58 GMT, Aleksey Shipilev wrote: >> Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: >> >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" >> >> test Insert.insertOffset(): failure >> java.lang.AssertionError: expected [??abc] but found [efabc] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:496) >> at org.testng.Assert.assertEquals(Assert.java:125) >> at org.testng.Assert.assertEquals(Assert.java:178) >> at org.testng.Assert.assertEquals(Assert.java:188) >> at Insert.insertOffset(Insert.java:45) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). >> >> void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { >> if (coder() == coder) { >> System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); >> } else { // this.coder == LATIN && coder == UTF16 >> StringLatin1.inflate(value, srcPos, dst, dstBegin, length); >> } >> } >> >> When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. >> >> Additional testing: >> - [x] Linux ARM32, affected test now passes >> - [x] Linux x86_64, affected test now passes >> - [x] Linux x86_64 `tier1` default, passes >> - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add the regression test case Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From james.laskey at oracle.com Tue Feb 2 15:18:20 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 2 Feb 2021 15:18:20 +0000 Subject: RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource [v2] In-Reply-To: References: Message-ID: <691C9658-E512-428B-ADB9-25EE4527FE4E@oracle.com> Here is the original document (it's available in the jigsaw wiki) How would you like it flushed out? Cheers, -- Jim > On Jan 31, 2021, at 11:40 AM, Jim Laskey wrote: > > I?ve been handing out the original jimage docs on request. Surprisingly, it?s still accurate. Will dig up on Monday to post. > > ?? > >> On Jan 31, 2021, at 11:07 AM, Alan Bateman wrote: >> >> ?On Wed, 27 Jan 2021 18:22:54 GMT, Jim Laskey wrote: >> >>>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >>>> >>>> Copyrights and rename containsLocation >>> >>> Nice clean up. LGTM >> >> @JimLaskey Do you have anything that documents the jimage format that could be checked into the repo to help with future changes in this change? Clearly any such document would need a warning in 96pt font that the format is JDK internal, submit to change from build to build, etc. but it could be helpful when working on this code. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/2212 From jlaskey at openjdk.java.net Tue Feb 2 15:34:41 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 2 Feb 2021 15:34:41 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: References: Message-ID: <3VQwxgVJpNtoTJzioVeb20sIXq83aB-dHgObFOl3-jg=.8fee6f20-a727-4642-bd67-bf7e5c1e95e3@github.com> On Tue, 2 Feb 2021 13:31:58 GMT, Aleksey Shipilev wrote: >> Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: >> >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" >> >> test Insert.insertOffset(): failure >> java.lang.AssertionError: expected [??abc] but found [efabc] >> at org.testng.Assert.fail(Assert.java:94) >> at org.testng.Assert.failNotEquals(Assert.java:496) >> at org.testng.Assert.assertEquals(Assert.java:125) >> at org.testng.Assert.assertEquals(Assert.java:178) >> at org.testng.Assert.assertEquals(Assert.java:188) >> at Insert.insertOffset(Insert.java:45) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). >> >> void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { >> if (coder() == coder) { >> System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); >> } else { // this.coder == LATIN && coder == UTF16 >> StringLatin1.inflate(value, srcPos, dst, dstBegin, length); >> } >> } >> >> When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. >> >> Additional testing: >> - [x] Linux ARM32, affected test now passes >> - [x] Linux x86_64, affected test now passes >> - [x] Linux x86_64 `tier1` default, passes >> - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add the regression test case Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From shade at openjdk.java.net Tue Feb 2 15:42:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 15:42:52 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Message-ID: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings STDERR: java.lang.OutOfMemoryError: Required length exceeds implementation limit at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) at HugeCapacity.testLatin1(HugeCapacity.java:49) at HugeCapacity.main(HugeCapacity.java:37) I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. Additional testing: - [x] Linux x86_64, affected test (default), passes - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes ------------- Commit messages: - 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Changes: https://git.openjdk.java.net/jdk/pull/2355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260934 Stats: 26 lines in 2 files changed: 20 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2355/head:pull/2355 PR: https://git.openjdk.java.net/jdk/pull/2355 From gziemski at openjdk.java.net Tue Feb 2 16:03:42 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 16:03:42 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: <3s1-hVjGvofyZ6o7jh6ayZWMp_RkPlt1Juig5U9zQfM=.3adf577e-6ee6-4f29-ba22-c7d15e742f3e@github.com> References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> <3s1-hVjGvofyZ6o7jh6ayZWMp_RkPlt1Juig5U9zQfM=.3adf577e-6ee6-4f29-ba22-c7d15e742f3e@github.com> Message-ID: On Mon, 1 Feb 2021 20:54:42 GMT, Ioi Lam wrote: >> src/java.base/share/native/libjava/check_version.c line 33: >> >>> 31: DEF_JNI_OnLoad(JavaVM *vm, void *reserved) >>> 32: { >>> 33: return JNI_VERSION_1_2; >> >> This leaves an entire file with one trivial function implementation. Can we remove the file and implement `DEF_JNI_OnLoad()` in `jni_util.h` (or some other existing suitable file) ? > > I am not sure if jni_utils.c is the right file (it defines the `JNU_XXX` functions that are used by other shared libraries). > > There are other .c files that have trivial `DEF_JNI_OnLoad` functions (e.g., java.base/share/native/libnio/nio_util.c). > > @AlanBateman do you have any suggestions? I'm fine with the way it is, just thought we might want to consider cleaning up a bit more, since it's a cleanup task itself. ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From gziemski at openjdk.java.net Tue Feb 2 16:03:40 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 16:03:40 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> Message-ID: <_PhEUVHOgMItPaEPIZH_KHEMPP6D4tPPTn0qjDLzd8Q=.7f3486a5-90f8-4ff2-931a-ea4dd238dc4b@github.com> On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote: >> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. >> - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed macos build Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Feb 2 16:17:00 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 2 Feb 2021 16:17:00 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v11] In-Reply-To: References: Message-ID: <37Z2VGvfNJKSJK1b9IMk_Z3ls82hRi0pebK1O7Y05ns=.af0cb1b1-fb81-475a-9cdf-32885dadc600@github.com> > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Using testNg Assert instead of assert. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/320b3054..224a104a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=09-10 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From asemenyuk at openjdk.java.net Tue Feb 2 17:12:48 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 2 Feb 2021 17:12:48 GMT Subject: RFR: JDK-8260335: [macos] Running app using relative path causes problems In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick wrote: > Fixing FileUtils.dirname() to skip over "/.". Changes requested by asemenyuk (Committer). src/jdk.jpackage/share/native/common/FileUtils.cpp line 57: > 55: tstring dirname(const tstring &path) { > 56: tstring::size_type pos; > 57: if (tstrings::endsWith(path, _T("/."))) { I'd add `|| tstrings::endsWith(path, _T("\."))` to cover similar case for Windows paths ------------- PR: https://git.openjdk.java.net/jdk/pull/2260 From kravikumar at openjdk.java.net Tue Feb 2 17:28:50 2021 From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar) Date: Tue, 2 Feb 2021 17:28:50 GMT Subject: RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a Message-ID: Hi Guys, Please review integrating tzdata2021a to JDK. JBS: https://bugs.openjdk.java.net/browse/JDK-8260356 The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html Thanks, Kiran ------------- Commit messages: - 8260356: (tz) Upgrade time-zone data to tzdata2021a Changes: https://git.openjdk.java.net/jdk/pull/2359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260356 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2359/head:pull/2359 PR: https://git.openjdk.java.net/jdk/pull/2359 From kizune at openjdk.java.net Tue Feb 2 17:38:41 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 2 Feb 2021 17:38:41 GMT Subject: RFR: JDK-8260335: [macos] Running app using relative path causes problems In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick wrote: > Fixing FileUtils.dirname() to skip over "/.". Aside of small change requested by @alexeysemenyukoracle looks fine. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2260 From naoto at openjdk.java.net Tue Feb 2 18:01:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 2 Feb 2021 18:01:40 GMT Subject: RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a In-Reply-To: References: Message-ID: <-0c4hj6JmNjRxa9spH1rQIsWtz6VFgngx3bgInZEljg=.35ff4b24-b0e8-4421-9667-f172cc860e66@github.com> On Tue, 2 Feb 2021 17:22:18 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review integrating tzdata2021a to JDK. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8260356 > > The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html > > Thanks, > Kiran Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2359 From shade at openjdk.java.net Tue Feb 2 18:03:47 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 18:03:47 GMT Subject: [jdk16] Integrated: 8260927: StringBuilder::insert is incorrect without Compact Strings In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 13:12:53 GMT, Aleksey Shipilev wrote: > Discovered it with ARM32 tier1 tests, which runs with -CompactStrings by default. But the bug is actually generic: > > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/Insert.java TEST_VM_OPTS="-XX:-CompactStrings" > > test Insert.insertOffset(): failure > java.lang.AssertionError: expected [??abc] but found [efabc] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at org.testng.Assert.assertEquals(Assert.java:188) > at Insert.insertOffset(Insert.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > I believe this is a regression from [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). > > void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) { > if (coder() == coder) { > System.arraycopy(value, srcPos, dst, dstBegin << coder, length << coder()); > } else { // this.coder == LATIN && coder == UTF16 > StringLatin1.inflate(value, srcPos, dst, dstBegin, length); > } > } > > When coder is `UTF16` (which it guaranteed to be without `CompactStrings`), then `srcPos` in `byte[]` array has to be adjusted by `coder` as well. > > Additional testing: > - [x] Linux ARM32, affected test now passes > - [x] Linux x86_64, affected test now passes > - [x] Linux x86_64 `tier1` default, passes > - [x] Linux x86_64 `tier1`, `-XX:-CompactStrings`, passes modulo two testbugs ([JDK-8260933](https://bugs.openjdk.java.net/browse/JDK-8260933), [JDK-8260934](https://bugs.openjdk.java.net/browse/JDK-8260934)) > - [x] Linux x86_64 `tier2` default, passes > - [x] Linux x86_64 `tier2`, `-XX:-CompactStrings`, passes This pull request has now been integrated. Changeset: 081fa3e7 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk16/commit/081fa3e7 Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 mod 8260927: StringBuilder::insert is incorrect without Compact Strings Reviewed-by: redestad, alanb, rriggs, jlaskey ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From shade at openjdk.java.net Tue Feb 2 18:03:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 2 Feb 2021 18:03:46 GMT Subject: [jdk16] RFR: 8260927: StringBuilder::insert is incorrect without Compact Strings [v2] In-Reply-To: <3VQwxgVJpNtoTJzioVeb20sIXq83aB-dHgObFOl3-jg=.8fee6f20-a727-4642-bd67-bf7e5c1e95e3@github.com> References: <3VQwxgVJpNtoTJzioVeb20sIXq83aB-dHgObFOl3-jg=.8fee6f20-a727-4642-bd67-bf7e5c1e95e3@github.com> Message-ID: On Tue, 2 Feb 2021 15:32:16 GMT, Jim Laskey wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add the regression test case > > Marked as reviewed by jlaskey (Reviewer). Thanks. GHA are green, `tier1`, `tier2` are clean, JDK 16 fix approval is there. I think it checks all the boxes. ------------- PR: https://git.openjdk.java.net/jdk16/pull/143 From herrick at openjdk.java.net Tue Feb 2 18:32:16 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 2 Feb 2021 18:32:16 GMT Subject: RFR: JDK-8260335: [macos] Running app using relative path causes problems [v2] In-Reply-To: References: Message-ID: > Fixing FileUtils.dirname() to skip over "/.". Andy Herrick 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 86 additional commits since the last revision: - Merge branch 'master' into JDK-8260335 - JDK-8260335: [macos] Running app using relative path causes problems - 8260522: Clean up warnings in hotspot JTReg runtime tests Reviewed-by: lfoltan, coleenp - 8259398: Super word not applied to a loop with byteArrayViewVarHandle Reviewed-by: vlivanov, thartmann, chagedorn - 8260669: Missing quotes in fixpath.sh Reviewed-by: tbell, iris, mikael, ihse - 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues Reviewed-by: alanb - 8257498: Remove useless skeleton predicates Reviewed-by: roland, thartmann - 8260591: Shenandoah: improve parallelism for concurrent thread root scans Reviewed-by: zgu, rkennke - 8259395: Patching automatic module with additional packages re-creates module without "requires java.base" Reviewed-by: attila, alanb - 8260577: Unused code in AbstractCompiler after Shark compiler removal Reviewed-by: shade, chagedorn, kvn - ... and 76 more: https://git.openjdk.java.net/jdk/compare/957d77d4...af31a50b ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2260/files - new: https://git.openjdk.java.net/jdk/pull/2260/files/6b5bfb28..af31a50b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2260&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2260&range=00-01 Stats: 24100 lines in 487 files changed: 8803 ins; 6126 del; 9171 mod Patch: https://git.openjdk.java.net/jdk/pull/2260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2260/head:pull/2260 PR: https://git.openjdk.java.net/jdk/pull/2260 From herrick at openjdk.java.net Tue Feb 2 18:32:19 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 2 Feb 2021 18:32:19 GMT Subject: RFR: JDK-8260335: [macos] Running app using relative path causes problems [v2] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 17:10:15 GMT, Alexey Semenyuk wrote: >> Andy Herrick 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 86 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8260335 >> - JDK-8260335: [macos] Running app using relative path causes problems >> - 8260522: Clean up warnings in hotspot JTReg runtime tests >> >> Reviewed-by: lfoltan, coleenp >> - 8259398: Super word not applied to a loop with byteArrayViewVarHandle >> >> Reviewed-by: vlivanov, thartmann, chagedorn >> - 8260669: Missing quotes in fixpath.sh >> >> Reviewed-by: tbell, iris, mikael, ihse >> - 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues >> >> Reviewed-by: alanb >> - 8257498: Remove useless skeleton predicates >> >> Reviewed-by: roland, thartmann >> - 8260591: Shenandoah: improve parallelism for concurrent thread root scans >> >> Reviewed-by: zgu, rkennke >> - 8259395: Patching automatic module with additional packages re-creates module without "requires java.base" >> >> Reviewed-by: attila, alanb >> - 8260577: Unused code in AbstractCompiler after Shark compiler removal >> >> Reviewed-by: shade, chagedorn, kvn >> - ... and 76 more: https://git.openjdk.java.net/jdk/compare/caf2c20d...af31a50b > > src/jdk.jpackage/share/native/common/FileUtils.cpp line 57: > >> 55: tstring dirname(const tstring &path) { >> 56: tstring::size_type pos; >> 57: if (tstrings::endsWith(path, _T("/."))) { > > I'd add `|| tstrings::endsWith(path, _T("\."))` to cover similar case for Windows paths yes - dirname not currently used this way on windows (passed a directory) but should make it work consistently) ------------- PR: https://git.openjdk.java.net/jdk/pull/2260 From vromero at openjdk.java.net Tue Feb 2 18:37:52 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 2 Feb 2021 18:37:52 GMT Subject: RFR: 8260959: remove RECORDS from PreviewFeature.Feature enum Message-ID: Please review this simple fix that is removing the RECORDS enum constant from the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant can be safely removed. Thanks, Vicente ------------- Commit messages: - 8260959: remove RECORDS from PreviewFeature.Feature enum Changes: https://git.openjdk.java.net/jdk/pull/2360/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260959 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2360/head:pull/2360 PR: https://git.openjdk.java.net/jdk/pull/2360 From gziemski at openjdk.java.net Tue Feb 2 18:55:48 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 18:55:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > support macos_aarch64 in hsdis Changes requested by gziemski (Committer). src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390: > 388: store_and_inc(_to, from_obj, NativeStack::intSpace); > 389: > 390: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches. We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 404: > 402: } else { > 403: store_and_inc(_to, from_obj, NativeStack::longSpace); > 404: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 418: > 416: } else { > 417: store_and_inc(_to, (*from_addr == 0) ? (intptr_t)NULL : (intptr_t) from_addr, wordSize); > 418: _num_int_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433: > 431: store_and_inc(_to, from_obj, NativeStack::floatSpace); > 432: > 433: _num_fp_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 448: > 446: } else { > 447: store_and_inc(_to, from_obj, NativeStack::doubleSpace); > 448: _num_fp_args++; `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else` We should be consistent. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: > 5269: // > 5270: void MacroAssembler::get_thread(Register dst) { > 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? src/hotspot/os/posix/signals_posix.cpp line 1297: > 1295: kern_return_t kr; > 1296: kr = task_set_exception_ports(mach_task_self(), > 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: > 91: CPU_MARVELL = 'V', > 92: CPU_INTEL = 'i', > 93: CPU_APPLE = 'a', The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Tue Feb 2 19:00:56 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 2 Feb 2021 19:00:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:52:29 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > Changes requested by gziemski (Committer). There were bunch of assembly code that I couldn't review. I also shallow reviewed the brand new files that were copies of the existing BSD x86_64 files - I hope I can get back to those when I figure out how to build/run these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Tue Feb 2 19:25:49 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 2 Feb 2021 19:25:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:23:04 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os/posix/signals_posix.cpp line 1297: > >> 1295: kern_return_t kr; >> 1296: kr = task_set_exception_ports(mach_task_self(), >> 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, > > Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From bchristi at openjdk.java.net Tue Feb 2 20:04:41 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 2 Feb 2021 20:04:41 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 23:03:55 GMT, Mahendra Chhipa wrote: >> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 126: >> >>> 124: Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1"); >>> 125: FileUtils.deleteFileTreeWithRetry(pkg1Dir); >>> 126: } >> >> I'm not convinced the `@AfterClass` method is necessary. Pre-cleanup is already done on LL94-95. And occasionally, test-generated artifacts are helpful in post-mortem analysis. > > To keep the source code repo clean from temporary generated files, these files are removed after test. Test logs have the information about the generated files for the Postmortem analysis. Test files shouldn't be written into the repository (repos are sometimes tested on read-only filesystems). Files should be written under JTwork/scratch/. ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Feb 2 21:00:00 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 2 Feb 2021 21:00:00 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v12] In-Reply-To: References: Message-ID: <0UV51jgP2AcM2C2iQZsdtEj8bnPs0PTK8l4NZMKn2Ns=.fd6053cf-6c3f-488e-84c5-ee939cb44cd7@github.com> > https://bugs.openjdk.java.net/browse/JDK-8183372 Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Generate the source files in JTWork directory. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2170/files - new: https://git.openjdk.java.net/jdk/pull/2170/files/224a104a..3c235ab0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2170&range=10-11 Stats: 16 lines in 1 file changed: 1 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2170/head:pull/2170 PR: https://git.openjdk.java.net/jdk/pull/2170 From bchristi at openjdk.java.net Tue Feb 2 21:08:49 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 2 Feb 2021 21:08:49 GMT Subject: RFR: JDK-8183372 : Refactor java/lang/Class shell tests to java [v12] In-Reply-To: <0UV51jgP2AcM2C2iQZsdtEj8bnPs0PTK8l4NZMKn2Ns=.fd6053cf-6c3f-488e-84c5-ee939cb44cd7@github.com> References: <0UV51jgP2AcM2C2iQZsdtEj8bnPs0PTK8l4NZMKn2Ns=.fd6053cf-6c3f-488e-84c5-ee939cb44cd7@github.com> Message-ID: On Tue, 2 Feb 2021 21:00:00 GMT, Mahendra Chhipa wrote: >> https://bugs.openjdk.java.net/browse/JDK-8183372 > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Generate the source files in JTWork directory. Looks good. Thanks for the changes. ------------- Marked as reviewed by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2170 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Feb 2 21:15:52 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 2 Feb 2021 21:15:52 GMT Subject: Integrated: JDK-8183372 : Refactor java/lang/Class shell tests to java In-Reply-To: References: Message-ID: <1gv5GnGUHq0JYSF8PnNOzVSaU67prABvpAX3Aoo4VMA=.835174f3-118d-4d99-adf6-e9de9dfc8672@github.com> On Wed, 20 Jan 2021 17:27:43 GMT, Mahendra Chhipa wrote: > https://bugs.openjdk.java.net/browse/JDK-8183372 This pull request has now been integrated. Changeset: 6dc3c6dc Author: Mahendra Chhipa Committer: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/6dc3c6dc Stats: 402 lines in 5 files changed: 151 ins; 212 del; 39 mod 8183372: Refactor java/lang/Class shell tests to java Reviewed-by: bchristi, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2170 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Feb 2 22:16:51 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 2 Feb 2021 22:16:51 GMT Subject: Integrated: JDK-8261003 : Bad Copyright header format after JDK-8183372 Message-ID: JDK-8261003 : Bad Copyright header format after JDK-8183372 ------------- Commit messages: - JDK-8261003 : Bad Copyright header format after JDK-8183372 Changes: https://git.openjdk.java.net/jdk/pull/2365/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2365&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261003 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2365.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2365/head:pull/2365 PR: https://git.openjdk.java.net/jdk/pull/2365 From bchristi at openjdk.java.net Tue Feb 2 22:16:51 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 2 Feb 2021 22:16:51 GMT Subject: Integrated: JDK-8261003 : Bad Copyright header format after JDK-8183372 In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:08:33 GMT, Mahendra Chhipa wrote: > JDK-8261003 : Bad Copyright header format after JDK-8183372 Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2365 From github.com+34924738+mahendrachhipa at openjdk.java.net Tue Feb 2 22:16:52 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Tue, 2 Feb 2021 22:16:52 GMT Subject: Integrated: JDK-8261003 : Bad Copyright header format after JDK-8183372 In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:08:33 GMT, Mahendra Chhipa wrote: > JDK-8261003 : Bad Copyright header format after JDK-8183372 This pull request has now been integrated. Changeset: 9af33392 Author: Mahendra Chhipa Committer: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/9af33392 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8261003: Bad Copyright header format after JDK-8183372 Reviewed-by: bchristi ------------- PR: https://git.openjdk.java.net/jdk/pull/2365 From lancea at openjdk.java.net Tue Feb 2 22:58:43 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 2 Feb 2021 22:58:43 GMT Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v4] In-Reply-To: <51Vs9v8X6Z2tq0pXjPEY1ey5CsYc6IBg4Dc_qBtcaW0=.2c8019f3-dd0c-495a-9179-9ad3169c576f@github.com> References: <51Vs9v8X6Z2tq0pXjPEY1ey5CsYc6IBg4Dc_qBtcaW0=.2c8019f3-dd0c-495a-9179-9ad3169c576f@github.com> Message-ID: <6nri_h_fiDxGPbQeWNXLf3Qcsr0JjaLOKF6xD7K63qM=.6b8bd671-55e3-4e5e-809f-95feade472ef@github.com> On Tue, 2 Feb 2021 10:40:01 GMT, Claes Redestad wrote: >> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward. >> - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on >> >> Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code. >> >> Testing: tier1-4 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Refactor out specific ZipException from checkedHash Thank you for the update Claes, the changes look fine ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2306 From dcubed at openjdk.java.net Tue Feb 2 23:13:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Feb 2021 23:13:00 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 11:59:08 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > support macos_aarch64 in hsdis For platform files that were copied from other ports to this port, if the file wasn't changed I presume the copyright years are left alone. If the file required changes for this port, I expect the year to be updated to 2021. How are you verifying that these copyright years are being properly managed on the new files? For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment explaining why one was landed in a particular place would help reviewers. Also see my comment about creating a new ThreadToNativeWithWXExecFromVM helper. I'm stopping my review with all the src/hotspot files done for now. make/autoconf/flags.m4 line 140: > 138: else > 139: MACOSX_VERSION_MIN=10.12.0 > 140: fi Not something that needs to be addressed here, but these changes illustrate that our collective use of macOSX/MACOSX/MacOSX names are tied to the fact that the macOS major version number was at 10 for a very long time. @magicus - Do we have an RFE to rename MACOSX or are we sticking with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? make/common/NativeCompilation.gmk line 1178: > 1176: endif > 1177: # This only works if the openjdk_codesign identity is present on the system. Let > 1178: # silently fail otherwise. Might want to add a comment here: # The '-f' option will replace an existing signature if one exists. src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 41: > 39: #define __ _masm-> > 40: > 41: //describe amount of space in bytes occupied by type on native stack nit - needs a space after `//` src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 83: > 81: // On macos/aarch64 native stack is packed, int/float are using only 4 bytes > 82: // on stack. Natural alignment for types are still in place, > 83: // for example double/long should be 8 bytes alligned nit typo: s/alligned/aligned/ And sentence should end with a period. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: > 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); > 322: > 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); I don't think this switch from `JavaThread::saved_fp_address_offset()` to `JavaFrameAnchor::saved_fp_address_offset()` is correct since `rthread` is still used and is a JavaThread*. The new code will give you: `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor The old code gave you: `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread Those are not the same things. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > 29: #include "asm/assembler.inline.hpp" > 30: #include "oops/compressedOops.hpp" > 31: #include "runtime/vm_version.hpp" It's not clear why this include needed to be added. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: > 808: #ifdef __APPLE__ > 809: // Less-than word types are stored one after another. > 810: // The code unable to handle this, bailout. Perhaps: // The code is unable to handle this so bailout. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 837: > 835: #ifdef __APPLE__ > 836: // Less-than word types are stored one after another. > 837: // The code unable to handle this, bailout. Perhaps: // The code is unable to handle this so bailout. src/hotspot/os/aix/os_aix.cpp line 69: > 67: #include "runtime/sharedRuntime.hpp" > 68: #include "runtime/statSampler.hpp" > 69: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 37: > 35: #include "runtime/init.hpp" > 36: #include "runtime/os.hpp" > 37: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os/windows/os_windows.cpp line 65: > 63: #include "runtime/sharedRuntime.hpp" > 64: #include "runtime/statSampler.hpp" > 65: #include "runtime/stubRoutines.inline.hpp" It is not clear why this include to inline-include change was made. src/hotspot/os_cpu/bsd_aarch64/atomic_bsd_aarch64.hpp line 59: > 57: } > 58: > 59: // __attribute__((unused)) on dest is to get rid of spurious GCC warnings. Is the GCC comment appropriate? Does this file get built with GCC or just Apple compilers? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 92: > 90: # define DEFAULT_MAIN_THREAD_STACK_PAGES 2048 > 91: # define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13 > 92: #endif Does this work around for Maveriks (10.9.0) need to be here? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 103: > 101: // 10.5 UNIX03 member name prefixes > 102: #define DU3_PREFIX(s, m) __ ## s.__ ## m > 103: # else Does this work around for macOS 10.5 need to be here? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195: > 193: frame os::get_sender_for_C_frame(frame* fr) { > 194: return frame(fr->link(), fr->link(), fr->sender_pc()); > 195: } Is this file going to be built by GCC or just macOS compilers? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221: > 219: assert(sig == info->si_signo, "bad siginfo"); > 220: } > 221: */ Should this code be deleted? From here and from where it was copied from if it is also commented out there... src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: > 361: address pc = os::Posix::ucontext_get_pc(uc); > 362: > 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means Is this TODO going to be resolved by this port? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 374: > 372: > 373: last_addr = (address) -1; > 374: } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means Is this TODO going to be resolved by this port? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: > 433: // | |\ Java thread created by VM does not have glibc > 434: // | glibc guard page | - guard, attached Java thread usually has > 435: // | |/ 1 glibc guard page. Is this code going to be built by GCC (with glibc) or will only macOS compilers and libraries be used? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: > 484: } > 485: } > 486: } This appears to be a mix for Mavericks (10.9) and 10.12 work arounds. Is this code needed by this project? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45: > 43: // Atomically copy 64 bits of data > 44: static void atomic_copy64(const volatile void *src, volatile void *dst) { > 45: *(jlong *) dst = *(const jlong *) src; Is this construct actually atomic on aarch64? src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43: > 41: assert(Thread::current() == this, "caller must be current thread"); > 42: return pd_get_top_frame(fr_addr, ucontext, isInJava); > 43: } Is AsyncGetCallTrace() being supported by this port? src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 43: > 41: > 42: private: > 43: 'private' usually has once space in front of it. Also why the blank line after it? src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 46: > 44: static void current_thread_enable_wx_impl(WXMode mode) { } > 45: > 46: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 41: > 39: > 40: private: > 41: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 44: > 42: static void current_thread_enable_wx_impl(WXMode mode) { } > 43: > 44: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 57: > 55: > 56: private: > 57: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 60: > 58: static void current_thread_enable_wx_impl(WXMode mode) { } > 59: > 60: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 43: > 41: > 42: private: > 43: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 46: > 44: static void current_thread_enable_wx_impl(WXMode mode) { } > 45: > 46: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 74: > 72: > 73: private: > 74: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 77: > 75: static void current_thread_enable_wx_impl(WXMode mode) { } > 76: > 77: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 36: > 34: > 35: private: > 36: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 39: > 37: static void current_thread_enable_wx_impl(WXMode mode) { } > 38: > 39: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 35: > 33: > 34: private: > 35: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 38: > 36: static void current_thread_enable_wx_impl(WXMode mode) { } > 37: > 38: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 54: > 52: > 53: private: > 54: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 57: > 55: static void current_thread_enable_wx_impl(WXMode mode) { } > 56: > 57: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 94: > 92: > 93: private: > 94: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 97: > 95: static void current_thread_enable_wx_impl(WXMode mode) { } > 96: > 97: private: I think this should 'public' (with one space in front of it). src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37: > 35: > 36: private: > 37: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 40: > 38: static void current_thread_enable_wx_impl(WXMode mode) { } > 39: > 40: public: 'public' usually has one space in front of it. src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 47: > 45: > 46: private: > 47: 'private' usually has one space in front of it. Also, why the blank line after it? src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 50: > 48: static void current_thread_enable_wx_impl(WXMode mode) { } > 49: > 50: public: 'public' usually has one space in front of it. src/hotspot/share/gc/shared/oopStorage.cpp line 40: > 38: #include "runtime/os.hpp" > 39: #include "runtime/safepoint.hpp" > 40: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline-include is not clear. src/hotspot/share/logging/logStream.hpp line 35: > 33: class LogStream : public outputStream { > 34: // see test/hotspot/gtest/logging/test_logStream.cpp > 35: friend class LogStreamTest; It's not clear why this change is made for this port. src/hotspot/share/prims/jni.cpp line 3930: > 3928: > 3929: // Go to the execute mode, the initial state of the thread on creation. > 3930: // Use os interface as the thread is not a java one anymore. Perhaps: s/not a java one anymore./not a JavaThread anymore./ src/hotspot/share/prims/nativeEntryPoint.cpp line 45: > 43: guarantee(status == JNI_OK && !env->ExceptionOccurred(), > 44: "register jdk.internal.invoke.NativeEntryPoint natives"); > 45: JNI_END I thought that jcheck caught a missing new-line? src/hotspot/share/runtime/globals.hpp line 1855: > 1853: \ > 1854: product(intx, UnguardOnExecutionViolation, 0, \ > 1855: "Unguard page and retry on no-execute fault " \ Taking away the "(Win32 only)" and not replacing it with new text feels wrong. I can't imagine that this flag works on any additional platforms except for macos-aarch64. src/hotspot/share/runtime/os.cpp line 58: > 56: #include "runtime/osThread.hpp" > 57: #include "runtime/sharedRuntime.hpp" > 58: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/objectMonitor.cpp line 52: > 50: #include "runtime/safepointMechanism.inline.hpp" > 51: #include "runtime/sharedRuntime.hpp" > 52: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/stubRoutines.cpp line 34: > 32: #include "runtime/timerTrace.hpp" > 33: #include "runtime/sharedRuntime.hpp" > 34: #include "runtime/stubRoutines.inline.hpp" The reason for switching from include to inline include is not clear. src/hotspot/share/runtime/stubRoutines.inline.hpp line 1: > 1: /* NOW I understand the reason for switching from include to inline-include. Is there a reason that this change is part of this project and not extracted into a separate RFE. That would reduce the number of files touched by this project. src/hotspot/share/runtime/thread.cpp line 3991: > 3989: JavaThread* thread = JavaThread::current(); > 3990: ThreadToNativeFromVM ttn(thread); > 3991: Thread::WXExecFromWriteSetter wx_exec; I saw somewhere in this review a comment about why this new WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM and I understand that not every current ThreadToNativeFromVM needs the new helper. If the vast majority of the ThreadToNativeFromVM locations need WXExecFromWriteSetter, then perhaps those locations that currently have a ThreadToNativeFromVM followed by the new WXExecFromWriteSetter should use a new helper: ThreadToNativeWithWXExecFromVM so we'll see changes from: ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM where we need them and hopefully a short comment can be added at the same time to explain the need for WXExec. This will allow us to easily distinguish ThreadToNativeFromVM locations that DO NOT need WXExec from those that DO need it. src/java.base/macosx/native/libjli/java_md_macosx.m line 210: > 208: if (preferredJVM == NULL) { > 209: #if defined(__i386__) > 210: preferredJVM = "client"; #if defined(__i386__) preferredJVM = "client"; Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From almatvee at openjdk.java.net Wed Feb 3 00:32:39 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 3 Feb 2021 00:32:39 GMT Subject: Integrated: 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 23:41:38 GMT, Alexander Matveev wrote: > We did not able to run "hdiutil convert" due to hdiutil did not able to acquire lock on DMG image file. In this condition we got "Resource busy" from "hdiutil detach" and on repeated attempt we was getting "File Not Found" error. According to some research "Resource Busy" is normal error message for "hdiutil detach" and can happen, but it should go away soon assuming nothing else is broken. I think due to we using "-force" flag we still ejected DMG image and left system in bad stage. After re-fixing repeated detach with force this issue is not longer reproducible. I still left code for forced detach if we did not able to detach it. Also, I added work around (in case we had to do forced detach) is to convert copy of original DMG image. This work around seems to solves problem as well when hdiutil cannot acquire lock on file. I also fixed in same way detach in our test helper. This pull request has now been integrated. Changeset: bec60432 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/bec60432 Stats: 74 lines in 3 files changed: 54 ins; 1 del; 19 mod 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' Reviewed-by: herrick, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/2345 From github.com+12689835+blindpirate at openjdk.java.net Wed Feb 3 00:52:59 2021 From: github.com+12689835+blindpirate at openjdk.java.net (Bo Zhang) Date: Wed, 3 Feb 2021 00:52:59 GMT Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache Message-ID: Previously, `ImageBufferCache` contains a ThreadLocal field which holds strong reference to `ImageBufferCache$BufferReference.class`. When loaded from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` in memory forever and never being GCed. The fix replace the old `ImageBufferCache$BufferReference` class with `WeakReference`, which is verified by provided test. ------------- Commit messages: - 8260621: Avoid memory leak in ImageBufferCache Changes: https://git.openjdk.java.net/jdk/pull/2307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260621 Stats: 123 lines in 2 files changed: 75 ins; 23 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/2307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2307/head:pull/2307 PR: https://git.openjdk.java.net/jdk/pull/2307 From github.com+12689835+blindpirate at openjdk.java.net Wed Feb 3 01:29:02 2021 From: github.com+12689835+blindpirate at openjdk.java.net (Bo Zhang) Date: Wed, 3 Feb 2021 01:29:02 GMT Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2] In-Reply-To: References: Message-ID: > Previously, `ImageBufferCache` contains a ThreadLocal field which holds > strong reference to `ImageBufferCache$BufferReference.class`. When loaded > from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` > in memory forever and never being GCed. > > The fix replace the old `ImageBufferCache$BufferReference` class with > `WeakReference`, which is verified by provided test. Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8260621: Avoid memory leak in ImageBufferCache Previously, `ImageBufferCache` contains a ThreadLocal field which holds strong reference to `ImageBufferCache$BufferReference.class`. When loaded from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` in memory forever and never being GCed. The fix replace the old `ImageBufferCache$BufferReference` class with `WeakReference`, which is verified by provided test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2307/files - new: https://git.openjdk.java.net/jdk/pull/2307/files/8d61d77d..27b55790 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2307/head:pull/2307 PR: https://git.openjdk.java.net/jdk/pull/2307 From mandy.chung at oracle.com Wed Feb 3 03:22:45 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Feb 2021 19:22:45 -0800 Subject: Trying to fix JDK-8013527 - 1st Prototype In-Reply-To: References: Message-ID: Hi Johannes, I reconsidered the solution I implemented for JDK-8013527 that I mentioned [1].? I finally had the time to get back to this. ? I see the merit of your idea to bind directly to an alternate implementation of MethodHandles::lookup taking an additional caller class parameter (but not any other caller-sensitive methods). Please see https://github.com/openjdk/jdk/pull/2367.?? I added you as a contributor in this PR. Mandy [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073220.html On 1/17/21 9:02 AM, Johannes Kuhn wrote: > JDK-8013527[1] has somehow become the umbrella bug for "Using > MethodHandles to call caller sensitive methods leads to interesting > results". > > To recap: A caller sensitive method knows about who called it, and can > behave differently when called from an other context. > Examples are: Class.forName, MethodHandles.lookup, Method.invoke... > > A MethodHandle on the other hand should not be caller sensitive. > To archive this, a MethodHandle will "bind" the lookup class as caller > for caller sensitive methods. > > This is currently done by injecting a hidden class (InjectedInvoker" > that acts as a trampoline for calling caller sensitive methods. > > This injected invoker shares many properties of the original caller: > Same ClassLoader, same Module, same Package, same ProtectionDomain, > but it's not the same class or a nestmate of it. > > For caller sensitive methods that do look at more than just the > injected invoker, this leads to "unexpected" results when called > through a MethodHandle: > > * MethodHandles.lookup() returns a full privileged lookup for the > injected invoker. > * jlr.Field.get*/set*, jlr.Constructor.newInstance, jlr.Method.invoke > may fail with an IllegalAccessException if the target is private. See > JDK-8257874[2]. > > ----------------------------------- > > After reading one of John Rose's comments[3], I thought that this > might be a way to solve this general problem. > > So I implemented some of it here[4]. > > The basic idea is that there is a private overload of the caller > sensitive method which accepts the caller as a tailing argument. > > The good news: > * tier1 Tests pass. > * ((Lookup) lookup.findStatic(MethodHandles.class, "lookup", > MethodType.methodType(Lookup.class)).invokeExact()).lookupClass() == > lookup.lookupClass(); > * JDK-8257874 can't be reproduced with Field.* or Constructor. > * Performance is likely better. (InjectedInvoker collects all > arguments into an Object[].) > > The bad news: > * If you use a MethodHandle to call Method.invoke for a caller > sensitive method, then you can still observe the injected invoker. > > ----------------------------------- > > Moving forward, there are 3 ways: > 1. Do nothing. Won't fix any bug. > 2. Use the current prototype, and accept Method.invoke is odd when > calling it through a MethodHandle. > 3. Go all in: > ? * Require **every** caller sensitive method to have a private overload. > ? * Method.invoke will also use that private overload. > > The problems with the 3rd approach are: > ? * What about methods that can be called virtually? > (Thread.getContextClassLoader()) > ? * Requires a few changes to MethodAccessor. Maybe implementing > JDK-6824466[5] first? > ? * What about methods that do stack walks? > > I have to think more about the problems listed above - but maybe you > have some input that could help me on that. > > - Johannes > > > [1]: https://bugs.openjdk.java.net/browse/JDK-8013527 > [2]: https://bugs.openjdk.java.net/browse/JDK-8257874 > [3]: > https://bugs.openjdk.java.net/browse/JDK-8020968?focusedCommentId=13611844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13611844 > [4]: https://github.com/openjdk/jdk/pull/2117/files > [5]: https://bugs.openjdk.java.net/browse/JDK-6824466 From mchung at openjdk.java.net Wed Feb 3 03:26:06 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 03:26:06 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors Message-ID: JDK-8013527: calling MethodHandles.lookup on itself leads to errors JDK-8257874: MethodHandle injected invoker doesn't have necessary private access Johannes Kuhn is also a contributor to this patch. A caller-sensitive method can behave differently depending on the identity of its immediate caller. If a method handle for a caller-sensitive method is requested, this resulting method handle behaves as if it were called from an instruction contained in the lookup class. The current implementation injects a trampoline class (aka the invoker class) which is the caller class invoking such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` because the caller-sensitive behavior depends on the module of the caller class, the class loader of the caller class, the accessibility of the caller class, or the protection domain of the caller class. The invoker class is a hidden class defined in the same runtime package with the same protection domain as the lookup class, which is why the current implementation works for all CSMs except `MethodHandles::lookup` which uses the caller class as the lookup class. Two issues with current implementation: 1. The invoker class only has the package access as the lookup class. It cannot access private members of the lookup class and its nest members. The fix is to make the invoker class as a nestmate of the lookup class. 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` object of an injected invoker class which is a bug. There are two alternatives: - define the invoker class with the lookup class as the class data such that `MethodHandles::lookup` will get the caller class from the class data if it's the injected invoker - Johannes' proposal [1]: detect if an alternate implementation with an additional trailing caller class parameter is present, use the alternate implementation and bind the method handle with the lookup class as the caller class argument. There has been several discussions on the improvement to support caller sensitive methods for example the calling sequences and security implication. I have looked at how each CSM uses the caller class. The second approach (i.e. defining an alternate implementation for a caller-sensitive method taking an additional caller class parameter) does not work for non-static non-final caller-sensitive method. In addition, it is not ideal to pollute the source code to provide an alternatve implementation for all 120+ caller-sensitive methods whereas the injected invoker works for all except `MethodHandles::lookup`. I propose to use both approaches. We can add an alternative implementation for a caller-sensitive method when desirable such as `MethodHandles::lookup` in this PR. For the injected invoker case, one could extract the original lookup class from class data if needed. test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that no new non-static non-final caller-sensitive method will be added to the JDK. I extend this test to catch that non-static non-final caller-sensitive method cannot have the alternate implementation taking the additional caller class parameter. This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html ------------- Commit messages: - clean up whitespace - revise the helper method - clean up - JDK-8013527: calling MethodHandles.lookup on itself leads to errors Changes: https://git.openjdk.java.net/jdk/pull/2367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8013527 Stats: 662 lines in 10 files changed: 620 ins; 9 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2367/head:pull/2367 PR: https://git.openjdk.java.net/jdk/pull/2367 From iklam at openjdk.java.net Wed Feb 3 03:59:43 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 3 Feb 2021 03:59:43 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: <_PhEUVHOgMItPaEPIZH_KHEMPP6D4tPPTn0qjDLzd8Q=.7f3486a5-90f8-4ff2-931a-ea4dd238dc4b@github.com> References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> <_PhEUVHOgMItPaEPIZH_KHEMPP6D4tPPTn0qjDLzd8Q=.7f3486a5-90f8-4ff2-931a-ea4dd238dc4b@github.com> Message-ID: On Tue, 2 Feb 2021 15:59:47 GMT, Gerard Ziemski wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed macos build > > Marked as reviewed by gziemski (Committer). Thanks @gerard-ziemski @magicus @AlanBateman @lfoltan for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From iklam at openjdk.java.net Wed Feb 3 03:59:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 3 Feb 2021 03:59:44 GMT Subject: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2] In-Reply-To: References: <188th_PzKn-dtdX8nHylqBZEa7Dddi7cU13bkoDzigc=.6a12ee5d-b027-4012-a137-0169440d61b6@github.com> <3s1-hVjGvofyZ6o7jh6ayZWMp_RkPlt1Juig5U9zQfM=.3adf577e-6ee6-4f29-ba22-c7d15e742f3e@github.com> Message-ID: On Tue, 2 Feb 2021 16:00:43 GMT, Gerard Ziemski wrote: >> I am not sure if jni_utils.c is the right file (it defines the `JNU_XXX` functions that are used by other shared libraries). >> >> There are other .c files that have trivial `DEF_JNI_OnLoad` functions (e.g., java.base/share/native/libnio/nio_util.c). >> >> @AlanBateman do you have any suggestions? > > I'm fine with the way it is, just thought we might want to consider cleaning up a bit more, since it's a cleanup task itself. Thanks Gerard. The main purpose of this PR is to clean up the JVM side. I'll leave the refactoring of check_version.c to the core-lib team. ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From iklam at openjdk.java.net Wed Feb 3 03:59:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 3 Feb 2021 03:59:45 GMT Subject: Integrated: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:40:54 GMT, Ioi Lam wrote: > - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed the same JDK library to use different version of HotSpot. However, HSX is no longer supported so this API should be removed. > - Implementations of APIs such as JVM_DTraceActivate, were removed in [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their declarations should be removed from jvm.h This pull request has now been integrated. Changeset: b9d4211b Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/b9d4211b Stats: 112 lines in 4 files changed: 0 ins; 110 del; 2 mod 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX Reviewed-by: alanb, lfoltan, gziemski, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/2338 From serb at openjdk.java.net Wed Feb 3 04:13:52 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 3 Feb 2021 04:13:52 GMT Subject: RFR: 8261010: Delete the Netbeans "default" license header Message-ID: Trivial cleanup, the "default" license header is removed in a few components. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/2368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261010 Stats: 14 lines in 3 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2368/head:pull/2368 PR: https://git.openjdk.java.net/jdk/pull/2368 From iris at openjdk.java.net Wed Feb 3 04:22:41 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 3 Feb 2021 04:22:41 GMT Subject: RFR: 8261010: Delete the Netbeans "default" license header In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov wrote: > Trivial cleanup, the "default" license header is removed in a few components. Trivial removal of template instructions. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2368 From psadhukhan at openjdk.java.net Wed Feb 3 04:41:40 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 3 Feb 2021 04:41:40 GMT Subject: RFR: 8261010: Delete the Netbeans "default" license header In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov wrote: > Trivial cleanup, the "default" license header is removed in a few components. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2368 From aph at openjdk.java.net Wed Feb 3 09:25:52 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 3 Feb 2021 09:25:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:03:50 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: > >> 5269: // >> 5270: void MacroAssembler::get_thread(Register dst) { >> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; > > The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? Surely this should be saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;``` Shouldn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Wed Feb 3 09:25:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 3 Feb 2021 09:25:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:49:36 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: > >> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >> 322: >> 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); > > I don't think this switch from `JavaThread::saved_fp_address_offset()` > to `JavaFrameAnchor::saved_fp_address_offset()` is correct since > `rthread` is still used and is a JavaThread*. The new code will give you: > > `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor > > The old code gave you: > > `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread > > Those are not the same things. I agree, I don't understand why this change was made. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45: > >> 43: // Atomically copy 64 bits of data >> 44: static void atomic_copy64(const volatile void *src, volatile void *dst) { >> 45: *(jlong *) dst = *(const jlong *) src; > > Is this construct actually atomic on aarch64? Yes. > src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37: > >> 35: >> 36: private: >> 37: > > 'private' usually has one space in front of it. > Also, why the blank line after it? It reads better with the blank line, and it's not in violation of HotSpot conventions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+652983+dasbrain at openjdk.java.net Wed Feb 3 11:18:40 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Wed, 3 Feb 2021 11:18:40 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 01:50:36 GMT, Mandy Chung wrote: > JDK-8013527: calling MethodHandles.lookup on itself leads to errors > JDK-8257874: MethodHandle injected invoker doesn't have necessary private access > > Johannes Kuhn is also a contributor to this patch. > > A caller-sensitive method can behave differently depending on the identity > of its immediate caller. If a method handle for a caller-sensitive method is > requested, this resulting method handle behaves as if it were called from an > instruction contained in the lookup class. The current implementation injects > a trampoline class (aka the invoker class) which is the caller class invoking > such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` > because the caller-sensitive behavior depends on the module of the caller class, > the class loader of the caller class, the accessibility of the caller class, or > the protection domain of the caller class. The invoker class is a hidden class > defined in the same runtime package with the same protection domain as the > lookup class, which is why the current implementation works for all CSMs except > `MethodHandles::lookup` which uses the caller class as the lookup class. > > Two issues with current implementation: > 1. The invoker class only has the package access as the lookup class. It cannot > access private members of the lookup class and its nest members. > > The fix is to make the invoker class as a nestmate of the lookup class. > > 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` > object of an injected invoker class which is a bug. > > There are two alternatives: > - define the invoker class with the lookup class as the class data such that > `MethodHandles::lookup` will get the caller class from the class data if > it's the injected invoker > - Johannes' proposal [1]: detect if an alternate implementation with an additional > trailing caller class parameter is present, use the alternate implementation > and bind the method handle with the lookup class as the caller class argument. > > There has been several discussions on the improvement to support caller sensitive > methods for example the calling sequences and security implication. I have > looked at how each CSM uses the caller class. The second approach (i.e. > defining an alternate implementation for a caller-sensitive method taking > an additional caller class parameter) does not work for non-static non-final > caller-sensitive method. In addition, it is not ideal to pollute the source > code to provide an alternatve implementation for all 120+ caller-sensitive methods > whereas the injected invoker works for all except `MethodHandles::lookup`. > > I propose to use both approaches. We can add an alternative implementation for > a caller-sensitive method when desirable such as `MethodHandles::lookup` in > this PR. For the injected invoker case, one could extract the original lookup > class from class data if needed. > > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that > no new non-static non-final caller-sensitive method will be added to the JDK. > I extend this test to catch that non-static non-final caller-sensitive method > cannot have the alternate implementation taking the additional caller class > parameter. > > This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html Thanks Mandy. Looks good, except the possibility for an attacker to teleport within the same nest. src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1205: > 1203: Class invokerClass = new Lookup(targetClass) > 1204: .makeHiddenClassDefiner(name, INJECTED_INVOKER_TEMPLATE, Set.of(NESTMATE)) > 1205: .defineClass(true, targetClass); Using the target class directly could lead to some unintended problems. An attacker can define it's own hidden class as nestmate and with a name ending in `$$InjectedInvoker`. This allows the attacker to "teleport" into a nestmate with full privileges. An attacker could then access `MethodHandles.classData`. Suggested remedy: Create a holder that is only visible to `java.lang.invoke`: /* package-private */ static class OriginalCallerHolder { final Class originalCaller; OriginalCallerHolder(Class originalCaller) { this.originalCaller = originalCaller; } } As this type is only visible inside `java.lang.invoke`, it can't be created without hacking into `java.lang.invoke`, at which point all bets are off anyway. (A previous commit was even more dangerous, as you can force `jlr.Proxy` to inject a class into your package with a `null`-PD) ------------- Changes requested by DasBrain at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/2367 From redestad at openjdk.java.net Wed Feb 3 11:45:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 11:45:52 GMT Subject: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v4] In-Reply-To: <6nri_h_fiDxGPbQeWNXLf3Qcsr0JjaLOKF6xD7K63qM=.6b8bd671-55e3-4e5e-809f-95feade472ef@github.com> References: <51Vs9v8X6Z2tq0pXjPEY1ey5CsYc6IBg4Dc_qBtcaW0=.2c8019f3-dd0c-495a-9179-9ad3169c576f@github.com> <6nri_h_fiDxGPbQeWNXLf3Qcsr0JjaLOKF6xD7K63qM=.6b8bd671-55e3-4e5e-809f-95feade472ef@github.com> Message-ID: On Tue, 2 Feb 2021 22:55:59 GMT, Lance Andersen wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor out specific ZipException from checkedHash > > Thank you for the update Claes, the changes look fine Thanks @LanceAndersen and @eirbjo for reviewing ------------- PR: https://git.openjdk.java.net/jdk/pull/2306 From redestad at openjdk.java.net Wed Feb 3 11:45:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 11:45:54 GMT Subject: Integrated: 8260617: Merge ZipFile encoding check with the initial hash calculation In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 00:54:46 GMT, Claes Redestad wrote: > - Merge checkEncoding into the byte[]-based normalizedHash. The latter is only used from ZipFile.initCEN right after the checkEncoding today, so verifying this is equivalent is straightforward. > - Factor out the logic to calculate hash, check encoding etc into the addEntry method to allow JITs to chew off larger chunks of the logic early on > > Roughly 1.2x speedup on the JarFileMeta microbenchmarks, which include the time required to open the jar file and thus exercising the optimized code. > > Testing: tier1-4 This pull request has now been integrated. Changeset: c8de943c Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/c8de943c Stats: 192 lines in 2 files changed: 67 ins; 83 del; 42 mod 8260617: Merge ZipFile encoding check with the initial hash calculation Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/2306 From redestad at openjdk.java.net Wed Feb 3 12:14:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 12:14:05 GMT Subject: RFR: 8261030: Avoid loading GenerateJLIClassesHelper at runtime Message-ID: This moves the tracing methods added to GenerateJLIClassesHelper in JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code meant for jlink. ------------- Commit messages: - Remove unused import, copyrights - Move tracing methods and constants from GenerateJLIClassesHelper to MethodHandleStatics Changes: https://git.openjdk.java.net/jdk/pull/2376/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2376&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261030 Stats: 69 lines in 4 files changed: 34 ins; 30 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2376/head:pull/2376 PR: https://git.openjdk.java.net/jdk/pull/2376 From redestad at openjdk.java.net Wed Feb 3 12:26:51 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 12:26:51 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM Message-ID: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. ------------- Commit messages: - Copyrights - Move class name checking for findBootstrapClass/findLoadedClass into native/VM Changes: https://git.openjdk.java.net/jdk/pull/2378/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261031 Stats: 20 lines in 3 files changed: 11 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2378/head:pull/2378 PR: https://git.openjdk.java.net/jdk/pull/2378 From redestad at openjdk.java.net Wed Feb 3 13:26:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 13:26:57 GMT Subject: RFR: 8261036: Reduce classes loaded by CleanerFactory initialization Message-ID: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). ------------- Commit messages: - Reduce classes loaded by CleanerFactory initialization Changes: https://git.openjdk.java.net/jdk/pull/2380/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261036 Stats: 49 lines in 2 files changed: 26 ins; 9 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2380/head:pull/2380 PR: https://git.openjdk.java.net/jdk/pull/2380 From redestad at openjdk.java.net Wed Feb 3 13:43:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 13:43:57 GMT Subject: RFR: 8261036: Reduce classes loaded by CleanerFactory initialization [v2] In-Reply-To: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> References: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> Message-ID: > This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Apply same pattern for newThread ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2380/files - new: https://git.openjdk.java.net/jdk/pull/2380/files/e7951e33..043067eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=00-01 Stats: 32 lines in 2 files changed: 12 ins; 10 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/2380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2380/head:pull/2380 PR: https://git.openjdk.java.net/jdk/pull/2380 From isipka at openjdk.java.net Wed Feb 3 14:11:42 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 3 Feb 2021 14:11:42 GMT Subject: Integrated: 8259265: Refactor UncaughtExceptions shell test as java test. In-Reply-To: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> References: <4X7LH_dpuKqcZGxizMls2cG80YGIxdBI-DO2K2BnMmQ=.dddd0edf-ce77-439d-a04b-8a435df9f857@github.com> Message-ID: On Wed, 2 Dec 2020 20:28:19 GMT, Ivan ?ipka wrote: > Refactor `test/jdk/java/lang/Thread/UncaughtExceptions.sh` as java test. This pull request has now been integrated. Changeset: 0ef93feb Author: Ivan ?ipka Committer: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/0ef93feb Stats: 411 lines in 2 files changed: 206 ins; 205 del; 0 mod 8259265: Refactor UncaughtExceptions shell test as java test. Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1578 From iignatyev at openjdk.java.net Wed Feb 3 14:12:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 3 Feb 2021 14:12:46 GMT Subject: RFR: 8259268: Refactor InheritIO shell test as java test [v3] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 19:46:14 GMT, Ivan ?ipka wrote: >> @iignatev could you please review? Thank you. >> >> note to self: >> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java you need to fix a missed comma in the copyright header to avoid tie1 failures. test/jdk/java/lang/ProcessBuilder/InheritIOTest.java line 2: > 1: /* > 2: * Copyright (c) 2020 Oracle and/or its affiliates. All rights reserved. missed comma ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1484 From jlaskey at openjdk.java.net Wed Feb 3 15:07:49 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 3 Feb 2021 15:07:49 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14] In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 00:15:16 GMT, Mark Reinhold wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update package info to credit LMX algorithm > > src/java.base/share/classes/java/util/random/RandomGenerator.java line 110: > >> 108: /** >> 109: * Returns an instance of {@link RandomGenerator} that utilizes the >> 110: * {@code name} algorithm. > > Shouldn't this method, and related methods, mention the fact that `RandomGenerator` instances are located as services? I see no mention of of that fact anywhere, unless I missed it, but I do see the `uses` and `provides` declarations in the module declaration. A paragraph explaining how services are used here, perhaps in the package specification, would be ideal. I agree. Will add. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From herrick at openjdk.java.net Wed Feb 3 15:11:54 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 3 Feb 2021 15:11:54 GMT Subject: RFR: JDK-8259927: Windows jpackage installer issues Message-ID: Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. ------------- Commit messages: - JDK-8259927: Windows jpackage installer issues Changes: https://git.openjdk.java.net/jdk/pull/2382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259927 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2382/head:pull/2382 PR: https://git.openjdk.java.net/jdk/pull/2382 From isipka at openjdk.java.net Wed Feb 3 16:02:11 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 3 Feb 2021 16:02:11 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v4] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: trying to manipulate effective jtreg classpath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/fc0af133..a5ef036d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=02-03 Stats: 397 lines in 2 files changed: 200 ins; 197 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From redestad at openjdk.java.net Wed Feb 3 16:11:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 16:11:08 GMT Subject: RFR: 8261036: Reduce classes loaded by CleanerFactory initialization [v3] In-Reply-To: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> References: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> Message-ID: > This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Only set priority if requested ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2380/files - new: https://git.openjdk.java.net/jdk/pull/2380/files/043067eb..89a16eb6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2380/head:pull/2380 PR: https://git.openjdk.java.net/jdk/pull/2380 From mchung at openjdk.java.net Wed Feb 3 17:23:44 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 17:23:44 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 10:52:41 GMT, Johannes Kuhn wrote: >> JDK-8013527: calling MethodHandles.lookup on itself leads to errors >> JDK-8257874: MethodHandle injected invoker doesn't have necessary private access >> >> Johannes Kuhn is also a contributor to this patch. >> >> A caller-sensitive method can behave differently depending on the identity >> of its immediate caller. If a method handle for a caller-sensitive method is >> requested, this resulting method handle behaves as if it were called from an >> instruction contained in the lookup class. The current implementation injects >> a trampoline class (aka the invoker class) which is the caller class invoking >> such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` >> because the caller-sensitive behavior depends on the module of the caller class, >> the class loader of the caller class, the accessibility of the caller class, or >> the protection domain of the caller class. The invoker class is a hidden class >> defined in the same runtime package with the same protection domain as the >> lookup class, which is why the current implementation works for all CSMs except >> `MethodHandles::lookup` which uses the caller class as the lookup class. >> >> Two issues with current implementation: >> 1. The invoker class only has the package access as the lookup class. It cannot >> access private members of the lookup class and its nest members. >> >> The fix is to make the invoker class as a nestmate of the lookup class. >> >> 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` >> object of an injected invoker class which is a bug. >> >> There are two alternatives: >> - define the invoker class with the lookup class as the class data such that >> `MethodHandles::lookup` will get the caller class from the class data if >> it's the injected invoker >> - Johannes' proposal [1]: detect if an alternate implementation with an additional >> trailing caller class parameter is present, use the alternate implementation >> and bind the method handle with the lookup class as the caller class argument. >> >> There has been several discussions on the improvement to support caller sensitive >> methods for example the calling sequences and security implication. I have >> looked at how each CSM uses the caller class. The second approach (i.e. >> defining an alternate implementation for a caller-sensitive method taking >> an additional caller class parameter) does not work for non-static non-final >> caller-sensitive method. In addition, it is not ideal to pollute the source >> code to provide an alternatve implementation for all 120+ caller-sensitive methods >> whereas the injected invoker works for all except `MethodHandles::lookup`. >> >> I propose to use both approaches. We can add an alternative implementation for >> a caller-sensitive method when desirable such as `MethodHandles::lookup` in >> this PR. For the injected invoker case, one could extract the original lookup >> class from class data if needed. >> >> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that >> no new non-static non-final caller-sensitive method will be added to the JDK. >> I extend this test to catch that non-static non-final caller-sensitive method >> cannot have the alternate implementation taking the additional caller class >> parameter. >> >> This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1205: > >> 1203: Class invokerClass = new Lookup(targetClass) >> 1204: .makeHiddenClassDefiner(name, INJECTED_INVOKER_TEMPLATE, Set.of(NESTMATE)) >> 1205: .defineClass(true, targetClass); > > Using the target class directly could lead to some unintended problems. > > An attacker can define it's own hidden class as nestmate and with a name ending in `$$InjectedInvoker`. > This allows the attacker to "teleport" into a nestmate with full privileges. > An attacker could then access `MethodHandles.classData`. > > Suggested remedy: Create a holder that is only visible to `java.lang.invoke`: > > /* package-private */ static class OriginalCallerHolder { > final Class originalCaller; > OriginalCallerHolder(Class originalCaller) { > this.originalCaller = originalCaller; > } > } > > As this type is only visible inside `java.lang.invoke`, it can't be created without hacking into `java.lang.invoke`, at which point all bets are off anyway. > > (A previous commit was even more dangerous, as you can force `jlr.Proxy` to inject a class into your package with a `null`-PD) Only `Lookup` with the original access can access `MethodHandles.classData`. A hidden class `HC$$InjectedInvoker/0x1234` can access private members of another class `C` in the same nest but not `C`'s class data. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From mchung at openjdk.java.net Wed Feb 3 17:27:41 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 17:27:41 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 17:20:40 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1205: >> >>> 1203: Class invokerClass = new Lookup(targetClass) >>> 1204: .makeHiddenClassDefiner(name, INJECTED_INVOKER_TEMPLATE, Set.of(NESTMATE)) >>> 1205: .defineClass(true, targetClass); >> >> Using the target class directly could lead to some unintended problems. >> >> An attacker can define it's own hidden class as nestmate and with a name ending in `$$InjectedInvoker`. >> This allows the attacker to "teleport" into a nestmate with full privileges. >> An attacker could then access `MethodHandles.classData`. >> >> Suggested remedy: Create a holder that is only visible to `java.lang.invoke`: >> >> /* package-private */ static class OriginalCallerHolder { >> final Class originalCaller; >> OriginalCallerHolder(Class originalCaller) { >> this.originalCaller = originalCaller; >> } >> } >> >> As this type is only visible inside `java.lang.invoke`, it can't be created without hacking into `java.lang.invoke`, at which point all bets are off anyway. >> >> (A previous commit was even more dangerous, as you can force `jlr.Proxy` to inject a class into your package with a `null`-PD) > > Only `Lookup` with the original access can access `MethodHandles.classData`. A hidden class `HC$$InjectedInvoker/0x1234` can access private members of another class `C` in the same nest but not `C`'s class data. > > I don't follow which previous commit you refer to more dangerous. Please elaborate. I don't see any security concern with class data. Last night, I had a second thought that the fix for these two JBS issues does not need the class data. It's more for a future use. I plan to revise it and drop class data in this fix anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From github.com+652983+dasbrain at openjdk.java.net Wed Feb 3 17:38:41 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Wed, 3 Feb 2021 17:38:41 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors In-Reply-To: References: Message-ID: <8SjmfywiihWSGFpL6UXHQDdqsB2N7eUZdPekqpsQtEA=.adb1d0b3-b211-4f4d-9783-1433f02868b9@github.com> On Wed, 3 Feb 2021 17:25:04 GMT, Mandy Chung wrote: >> Only `Lookup` with the original access can access `MethodHandles.classData`. A hidden class `HC$$InjectedInvoker/0x1234` can access private members of another class `C` in the same nest but not `C`'s class data. >> >> I don't follow which previous commit you refer to more dangerous. Please elaborate. I don't see any security concern with class data. > > Last night, I had a second thought that the fix for these two JBS issues does not need the class data. It's more for a future use. I plan to revise it and drop class data in this fix anyway. You are right, got it confused with the future use. With this fix, MethodHandle -> Method.invoke -> MethodHandles.lookup() will still return a lookup on the injected invoker. I somehow missed that this is not part of the fix, but for the future use. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From mchung at openjdk.java.net Wed Feb 3 17:50:46 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 17:50:46 GMT Subject: RFR: 8261030: Avoid loading GenerateJLIClassesHelper at runtime In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 12:08:58 GMT, Claes Redestad wrote: > This moves the tracing methods added to GenerateJLIClassesHelper in JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code meant for jlink. Marked as reviewed by mchung (Reviewer). src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 68: > 66: // classes that have been or could have be pre-generated > 67: static final String LF_RESOLVE = "[LF_RESOLVE]"; > 68: static final String SPECIES_RESOLVE = "[SPECIES_RESOLVE]"; It is okay with me to simply hardcode these strings in GenerateJLIClassesHelper and the trace methods. src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 121: > 119: > 120: /*non-public*/ > 121: static void traceLambdaForm(String name, MethodType type, Class holder, MemberName resolvedMember) { It'd be help to add a comment describing what these trace methods are for. ------------- PR: https://git.openjdk.java.net/jdk/pull/2376 From rriggs at openjdk.java.net Wed Feb 3 18:00:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 3 Feb 2021 18:00:44 GMT Subject: RFR: 8261036: Reduce classes loaded by CleanerFactory initialization [v3] In-Reply-To: References: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> Message-ID: On Wed, 3 Feb 2021 16:11:08 GMT, Claes Redestad wrote: >> This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Only set priority if requested Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 64: > 62: * Returns a new InnocuousThread with its context class loader > 63: * set to the system class loader, inheriting the current thread priority > 64: */ Needs a period at the end of the sentence. Which is getting too long for the method summary. (Even though javadoc is not usually generated for this implementation class). Split the qualification about thread priority into a separate sentence. src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 88: > 86: /** > 87: * Returns a new InnocuousThread with an auto-generated thread name, > 88: * inheriting the current thread priority. ditto; separate sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/2380 From mchung at openjdk.java.net Wed Feb 3 18:40:15 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 18:40:15 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors [v2] In-Reply-To: References: Message-ID: > JDK-8013527: calling MethodHandles.lookup on itself leads to errors > JDK-8257874: MethodHandle injected invoker doesn't have necessary private access > > Johannes Kuhn is also a contributor to this patch. > > A caller-sensitive method can behave differently depending on the identity > of its immediate caller. If a method handle for a caller-sensitive method is > requested, this resulting method handle behaves as if it were called from an > instruction contained in the lookup class. The current implementation injects > a trampoline class (aka the invoker class) which is the caller class invoking > such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` > because the caller-sensitive behavior depends on the module of the caller class, > the class loader of the caller class, the accessibility of the caller class, or > the protection domain of the caller class. The invoker class is a hidden class > defined in the same runtime package with the same protection domain as the > lookup class, which is why the current implementation works for all CSMs except > `MethodHandles::lookup` which uses the caller class as the lookup class. > > Two issues with current implementation: > 1. The invoker class only has the package access as the lookup class. It cannot > access private members of the lookup class and its nest members. > > The fix is to make the invoker class as a nestmate of the lookup class. > > 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` > object of an injected invoker class which is a bug. > > There are two alternatives: > - define the invoker class with the lookup class as the class data such that > `MethodHandles::lookup` will get the caller class from the class data if > it's the injected invoker > - Johannes' proposal [1]: detect if an alternate implementation with an additional > trailing caller class parameter is present, use the alternate implementation > and bind the method handle with the lookup class as the caller class argument. > > There has been several discussions on the improvement to support caller sensitive > methods for example the calling sequences and security implication. I have > looked at how each CSM uses the caller class. The second approach (i.e. > defining an alternate implementation for a caller-sensitive method taking > an additional caller class parameter) does not work for non-static non-final > caller-sensitive method. In addition, it is not ideal to pollute the source > code to provide an alternatve implementation for all 120+ caller-sensitive methods > whereas the injected invoker works for all except `MethodHandles::lookup`. > > I propose to use both approaches. We can add an alternative implementation for > a caller-sensitive method when desirable such as `MethodHandles::lookup` in > this PR. For the injected invoker case, one could extract the original lookup > class from class data if needed. > > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that > no new non-static non-final caller-sensitive method will be added to the JDK. > I extend this test to catch that non-static non-final caller-sensitive method > cannot have the alternate implementation taking the additional caller class > parameter. > > This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Support MethodHandles::lookup called via Method::invoke via MethodHandle ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2367/files - new: https://git.openjdk.java.net/jdk/pull/2367/files/3764fd0a..228d29f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2367&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2367&range=00-01 Stats: 81 lines in 3 files changed: 48 ins; 31 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2367/head:pull/2367 PR: https://git.openjdk.java.net/jdk/pull/2367 From mchung at openjdk.java.net Wed Feb 3 18:40:15 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 18:40:15 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors [v2] In-Reply-To: <8SjmfywiihWSGFpL6UXHQDdqsB2N7eUZdPekqpsQtEA=.adb1d0b3-b211-4f4d-9783-1433f02868b9@github.com> References: <8SjmfywiihWSGFpL6UXHQDdqsB2N7eUZdPekqpsQtEA=.adb1d0b3-b211-4f4d-9783-1433f02868b9@github.com> Message-ID: On Wed, 3 Feb 2021 17:35:30 GMT, Johannes Kuhn wrote: >> Last night, I had a second thought that the fix for these two JBS issues does not need the class data. It's more for a future use. I plan to revise it and drop class data in this fix anyway. > > You are right, got it confused with the future use. > > With this fix, MethodHandle -> Method.invoke -> MethodHandles.lookup() will still return a lookup on the injected invoker. > I somehow missed that this is not part of the fix, but for the future use. `MethodHandle -> Method.invoke -> MethodHandles.lookup() ` is a corner case that can be fixed easily using the class data approach. See the new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From github.com+652983+dasbrain at openjdk.java.net Wed Feb 3 19:44:44 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Wed, 3 Feb 2021 19:44:44 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors [v2] In-Reply-To: References: <8SjmfywiihWSGFpL6UXHQDdqsB2N7eUZdPekqpsQtEA=.adb1d0b3-b211-4f4d-9783-1433f02868b9@github.com> Message-ID: <8Y_yJ4VOYzgvDbRg5egat3PqfHNRuRqSFow4fiEI4To=.9c78ec03-f78f-43e0-8773-c9503236e301@github.com> On Wed, 3 Feb 2021 18:34:55 GMT, Mandy Chung wrote: >> You are right, got it confused with the future use. >> >> With this fix, MethodHandle -> Method.invoke -> MethodHandles.lookup() will still return a lookup on the injected invoker. >> I somehow missed that this is not part of the fix, but for the future use. > > `MethodHandle -> Method.invoke -> MethodHandles.lookup() ` is a corner case that can be fixed easily using the class data approach. See the new commit. The security issue I mentioned was in an other branch, method-invoke. I used commit https://github.com/mlchung/jdk/commit/4a3c914f1b46cf84b42f6b6bc19d421955faac3f (i.e. before strengthening the injected invoker checks) to test the [my exploit](https://gist.github.com/DasBrain/4dda6cc3a13e1636afe17e6a02ec3d12). (Yes, full sandbox escape.) I hope the same is not possible with the nestmate requirement. PS.: Hidden Class -> MethodHandle -> Method.invoke -> MethodHandles might break due to mangling of the hidden class name for the injected invoker. Will write a test. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From mchung at openjdk.java.net Wed Feb 3 19:55:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 19:55:45 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM In-Reply-To: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Wed, 3 Feb 2021 12:21:30 GMT, Claes Redestad wrote: > This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. I'm unsure the benefit of moving the check done by `checkName` to the VM but `preDefineClass` still calls `checkName`. The overhead of `checkName` should be fairly negligible? src/java.base/share/native/libjava/ClassLoader.c line 291: > 289: } > 290: // disallow slashes in input, change '.' to '/' > 291: if (verifyFixClassname(clname)) { perhaps we should replace all use of `fixClassname` with `verifyFixClassname` and remove `fixClassname`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From mchung at openjdk.java.net Wed Feb 3 19:58:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 3 Feb 2021 19:58:55 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors [v2] In-Reply-To: <8Y_yJ4VOYzgvDbRg5egat3PqfHNRuRqSFow4fiEI4To=.9c78ec03-f78f-43e0-8773-c9503236e301@github.com> References: <8SjmfywiihWSGFpL6UXHQDdqsB2N7eUZdPekqpsQtEA=.adb1d0b3-b211-4f4d-9783-1433f02868b9@github.com> <8Y_yJ4VOYzgvDbRg5egat3PqfHNRuRqSFow4fiEI4To=.9c78ec03-f78f-43e0-8773-c9503236e301@github.com> Message-ID: On Wed, 3 Feb 2021 19:42:16 GMT, Johannes Kuhn wrote: >> `MethodHandle -> Method.invoke -> MethodHandles.lookup() ` is a corner case that can be fixed easily using the class data approach. See the new commit. > > The security issue I mentioned was in an other branch, method-invoke. > > I used commit https://github.com/mlchung/jdk/commit/4a3c914f1b46cf84b42f6b6bc19d421955faac3f (i.e. before strengthening the injected invoker checks) to test the [my exploit](https://gist.github.com/DasBrain/4dda6cc3a13e1636afe17e6a02ec3d12). (Yes, full sandbox escape.) > > I hope the same is not possible with the nestmate requirement. > > PS.: Hidden Class -> MethodHandle -> Method.invoke -> MethodHandles might break due to mangling of the hidden class name for the injected invoker. Will write a test. Well, my branch `method-invoke` is a prototype and work-in-progress. I won't dig too much to it. Do you reproduce the issue with this patch? The fix will ensure it's the invoker class injected by BindCaller. ------------- PR: https://git.openjdk.java.net/jdk/pull/2367 From akozlov at openjdk.java.net Wed Feb 3 20:01:15 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:01:15 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Add comments to WX transitions + minor change of placements - Use macro conditionals instead of empty functions - Add W^X to tests - Do not require known W^X state - Revert w^x in gtests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/3c705ae5..80827176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=08-09 Stats: 444 lines in 64 files changed: 112 ins; 278 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:01:16 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:01:16 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > For platform files that were copied from other ports to this port, if the file wasn't > changed I presume the copyright years are left alone. If the file required changes > for this port, I expect the year to be updated to 2021. How are you verifying that > these copyright years are being properly managed on the new files? > > For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment > explaining why one was landed in a particular place would help reviewers. > Also see my comment about creating a new ThreadToNativeWithWXExecFromVM > helper. > > I'm stopping my review with all the src/hotspot files done for now. Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From kustos at gmx.net Wed Feb 3 20:02:08 2021 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 3 Feb 2021 21:02:08 +0100 Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) In-Reply-To: References: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com> Message-ID: On 17.01.21 18:48, Philippe Marschall wrote: > ... > > To be honest backing out of the StreamDecoder changes looks like a good > comprise to me to reduce the risk while still improving throughput and > reducing allocation rate, especially in the on-heap path. I gave it some more thought and propose to back out of the StreamDecoder changes. While that leaves some optimization potential unused it keeps the patch smaller, the risk lower and avoids any throughput regressions. > Looking a bit further I wonder if CharArrayReader and StringReader > should implement #read(CharBuffer) as well and call CharBuffer#put > directly. And maybe even #transferTo(Writer). I did have a look at this [1] for coders LATIN1(0) and UTF16(1) as well as 128 and 1024 char sized readers for both on- and off-heap buffers. CharArrayReader#read(CharBuffer) on-heap Higher throughput than master but slightly lower throughput than the current PR. I don? t know why that is, maybe the additional checks in CharBuffer show up here. off-heap Higher throughput than master or the PR, all intermediate allocation is gone. StringReader#read(CharBuffer) on-heap Higher throughput than master but slightly lower throughput than the current PR. I don? t know why that is, maybe the additional checks in CharBuffer show up here. The situation is similar to CharArrayReader. off-heap Lower throughput but all intermediate allocation is gone. What shows up here is the lack of an optimized #put(String) method for off-heap CharBuffers like was done in JDK-8011135 for on-heap buffers. Based on this is propose to add CharArrayReader#read(CharBuffer), assuming it is still in the scope of the bug. I wouldn't add StringReader#read(CharBuffer) due to the throughput regression. I think #transferTo(Writer) would be out of the scope of the bug. Is that ok? [1] https://github.com/marschall/reader-benchmarks/blob/master/src/main/java/com/github/marschall/readerbenchmarks/CharsequenceReaderBenchmarks.java Cheers Philippe From jlaskey at openjdk.java.net Wed Feb 3 20:03:04 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 3 Feb 2021 20:03:04 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v15] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/38369702..96f98765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=13-14 Stats: 599 lines in 8 files changed: 311 ins; 253 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From akozlov at openjdk.java.net Wed Feb 3 20:11:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 19:57:24 GMT, Anton Kozlov wrote: >> For platform files that were copied from other ports to this port, if the file wasn't >> changed I presume the copyright years are left alone. If the file required changes >> for this port, I expect the year to be updated to 2021. How are you verifying that >> these copyright years are being properly managed on the new files? >> >> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment >> explaining why one was landed in a particular place would help reviewers. >> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM >> helper. >> >> I'm stopping my review with all the src/hotspot files done for now. > > Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. > > The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. > I wonder if this is the right choice > ... > ``` > OopStorageParIterPerf::~OopStorageParIterPerf() { > ... > ``` > The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From mikael at openjdk.java.net Wed Feb 3 20:11:50 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov wrote: >> Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten. >> >> The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions. > >> I wonder if this is the right choice >> ... >> ``` >> OopStorageParIterPerf::~OopStorageParIterPerf() { >> ... >> ``` >> > > The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. > > I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. > > I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. > > Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. > > W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> Message-ID: On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov wrote: >> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like: >> class ThreadInVMfromNative : public ThreadStateTransition { >> ResetNoHandleMark __rnhm; >> >> We can look at it with cleaning up the thread transitions RFE or as a follow-on. If every line of ThreadInVMfromNative has to have one of these Thread::WXWriteVerifier __wx_write; people are going to miss them when adding the former. > > Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this. I've dropped this transition here and in similar places after state tracking always available. As a benefit, there are few places really using the setter and all of them are tied to VM_ENTRY macro or similar one. I expect we don't need to do W^X management near every java thread state change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:51 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2] In-Reply-To: References: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com> <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com> <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com> Message-ID: On Tue, 26 Jan 2021 12:01:30 GMT, Coleen Phillimore wrote: >> I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. >> * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. >> * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance. >> >> If such costs are negligible, I can do as suggested. > > I really just want the minimal number of lines of code and hooks in thread.hpp. You can still access it through the thread, just like these lines currently. Look at HandshakeState as an example. Please take a look at the recent changes. Changes in thread.hpp were reduced: https://github.com/openjdk/jdk/pull/2200/files#diff-abdc409967d04172ecc20e3747aa55a79e755584d570b57c4d58902a9813d188 thread.inline.hpp provides definitions of accessors (non-trivial): https://github.com/openjdk/jdk/pull/2200/files#diff-3a29f7f952bf2bd936f49e97cb3b86a7324851133e879c142dec724455310b50 And new threadWXSetters.hpp defines RAII context setter: https://github.com/openjdk/jdk/pull/2200/files#diff-6424782ec43941031282f079e89adaa76d341ce340a3b78b0e9657358ec16278 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 20:11:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 20:11:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 19:23:16 GMT, Bernhard Urban-Forster wrote: >> src/hotspot/os/posix/signals_posix.cpp line 1297: >> >>> 1295: kern_return_t kr; >>> 1296: kr = task_set_exception_ports(mach_task_self(), >>> 1297: EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC, >> >> Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here? > > See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: `// gdb installs both standard BSD signal handlers, and mach exception` `// handlers. By replacing the existing task exception handler, we disable gdb's mach` `// exception handling, while leaving the standard BSD signal handlers functional.` Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:53 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 23:03:45 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/runtime/thread.cpp line 3991: > >> 3989: JavaThread* thread = JavaThread::current(); >> 3990: ThreadToNativeFromVM ttn(thread); >> 3991: Thread::WXExecFromWriteSetter wx_exec; > > I saw somewhere in this review a comment about why this new > WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM > and I understand that not every current ThreadToNativeFromVM needs > the new helper. If the vast majority of the ThreadToNativeFromVM > locations need WXExecFromWriteSetter, then perhaps those locations > that currently have a ThreadToNativeFromVM followed by the new > WXExecFromWriteSetter should use a new helper: > > ThreadToNativeWithWXExecFromVM > > so we'll see changes from: > > ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM > > where we need them and hopefully a short comment can be added > at the same time to explain the need for WXExec. This will allow us > to easily distinguish ThreadToNativeFromVM locations that DO NOT > need WXExec from those that DO need it. With a small overhead for tracking the current W^X state, I avoided WXExecFromWriteSetter near ThreadToNativeFromVM at all. New ThreadWXEnable(WXExec) is used only to call a generated function. More common ThreadWXEnable(WXWrite) is tied to JVM entry functions. I added comments for functions that are not clear to be entries, although they are. Thank you for the suggestion! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:11:54 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:11:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:00:06 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390: > >> 388: store_and_inc(_to, from_obj, NativeStack::intSpace); >> 389: >> 390: _num_int_args++; > > `pass_byte()` and `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches. > > We should be consistent. Agree. I'm going to do as much refactoring as needed before this patch under JDK-8261071 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 3 20:16:52 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 3 Feb 2021 20:16:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 09:14:24 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271: >> >>> 5269: // >>> 5270: void MacroAssembler::get_thread(Register dst) { >>> 5271: RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst; >> >> The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ? > > Surely this should be > > saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;``` > > Shouldn't it? Interesting, I wonder why it has built successfully on Linux. I'm going to fix this under as JDK-8261072 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From isipka at openjdk.java.net Wed Feb 3 20:20:09 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 3 Feb 2021 20:20:09 GMT Subject: RFR: 8259268: Refactor InheritIO shell test as java test [v4] In-Reply-To: References: Message-ID: > @iignatev could you please review? Thank you. > > note to self: > jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1484/files - new: https://git.openjdk.java.net/jdk/pull/1484/files/75096d42..53e0a4a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1484/head:pull/1484 PR: https://git.openjdk.java.net/jdk/pull/1484 From isipka at openjdk.java.net Wed Feb 3 20:20:09 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 3 Feb 2021 20:20:09 GMT Subject: RFR: 8259268: Refactor InheritIO shell test as java test [v3] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 14:08:46 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/ProcessBuilder/InheritIOTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020 Oracle and/or its affiliates. All rights reserved. > > missed comma updated, thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From gziemski at openjdk.java.net Wed Feb 3 20:32:47 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 20:32:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:04:18 GMT, Gerard Ziemski wrote: >> See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`. > > Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. > > We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: > > `// gdb installs both standard BSD signal handlers, and mach exception` > `// handlers. By replacing the existing task exception handler, we disable gdb's mach` > `// exception handling, while leaving the standard BSD signal handlers functional.` > > Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` Remaining questions: a) why we need `EXC_MASK_ARITHMETIC` ? b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From asemenyuk at openjdk.java.net Wed Feb 3 21:13:42 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 3 Feb 2021 21:13:42 GMT Subject: RFR: JDK-8259927: Windows jpackage installer issues In-Reply-To: References: Message-ID: <72SnnlVmfjL2lzWQlB4r0yZ_qjblx_MwHhCh-VuxhCk=.dbf8a45b-f25d-4906-9da7-75644e63892e@github.com> On Wed, 3 Feb 2021 14:08:13 GMT, Andy Herrick wrote: > Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2382 From github.com+652983+dasbrain at openjdk.java.net Wed Feb 3 21:43:43 2021 From: github.com+652983+dasbrain at openjdk.java.net (Johannes Kuhn) Date: Wed, 3 Feb 2021 21:43:43 GMT Subject: RFR: 8013527: calling MethodHandles.lookup on itself leads to errors [v2] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 18:40:15 GMT, Mandy Chung wrote: >> JDK-8013527: calling MethodHandles.lookup on itself leads to errors >> JDK-8257874: MethodHandle injected invoker doesn't have necessary private access >> >> Johannes Kuhn is also a contributor to this patch. >> >> A caller-sensitive method can behave differently depending on the identity >> of its immediate caller. If a method handle for a caller-sensitive method is >> requested, this resulting method handle behaves as if it were called from an >> instruction contained in the lookup class. The current implementation injects >> a trampoline class (aka the invoker class) which is the caller class invoking >> such caller-sensitive method handle. It works in all CSMs except `MethodHandles::lookup` >> because the caller-sensitive behavior depends on the module of the caller class, >> the class loader of the caller class, the accessibility of the caller class, or >> the protection domain of the caller class. The invoker class is a hidden class >> defined in the same runtime package with the same protection domain as the >> lookup class, which is why the current implementation works for all CSMs except >> `MethodHandles::lookup` which uses the caller class as the lookup class. >> >> Two issues with current implementation: >> 1. The invoker class only has the package access as the lookup class. It cannot >> access private members of the lookup class and its nest members. >> >> The fix is to make the invoker class as a nestmate of the lookup class. >> >> 2. `MethodHandles::lookup` if invoked via a method handle produces a `Lookup` >> object of an injected invoker class which is a bug. >> >> There are two alternatives: >> - define the invoker class with the lookup class as the class data such that >> `MethodHandles::lookup` will get the caller class from the class data if >> it's the injected invoker >> - Johannes' proposal [1]: detect if an alternate implementation with an additional >> trailing caller class parameter is present, use the alternate implementation >> and bind the method handle with the lookup class as the caller class argument. >> >> There has been several discussions on the improvement to support caller sensitive >> methods for example the calling sequences and security implication. I have >> looked at how each CSM uses the caller class. The second approach (i.e. >> defining an alternate implementation for a caller-sensitive method taking >> an additional caller class parameter) does not work for non-static non-final >> caller-sensitive method. In addition, it is not ideal to pollute the source >> code to provide an alternatve implementation for all 120+ caller-sensitive methods >> whereas the injected invoker works for all except `MethodHandles::lookup`. >> >> I propose to use both approaches. We can add an alternative implementation for >> a caller-sensitive method when desirable such as `MethodHandles::lookup` in >> this PR. For the injected invoker case, one could extract the original lookup >> class from class data if needed. >> >> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSM.java ensures that >> no new non-static non-final caller-sensitive method will be added to the JDK. >> I extend this test to catch that non-static non-final caller-sensitive method >> cannot have the alternate implementation taking the additional caller class >> parameter. >> >> This fix for JDK-8013527 is needed by the prototype for JDK-6824466 I'm working on. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-January/073184.html > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Support MethodHandles::lookup called via Method::invoke via MethodHandle Looks good. ------------- Marked as reviewed by DasBrain at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/2367 From martin at openjdk.java.net Wed Feb 3 22:06:55 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Wed, 3 Feb 2021 22:06:55 GMT Subject: RFR: 8260664: Phaser.arrive() memory consistency effects Message-ID: 8260664: Phaser.arrive() memory consistency effects ------------- Commit messages: - JDK-8260664 Changes: https://git.openjdk.java.net/jdk/pull/2388/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260664 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2388.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2388/head:pull/2388 PR: https://git.openjdk.java.net/jdk/pull/2388 From burban at openjdk.java.net Wed Feb 3 22:19:58 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Wed, 3 Feb 2021 22:19:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:29:48 GMT, Gerard Ziemski wrote: >> Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then. >> >> We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb: >> >> `// gdb installs both standard BSD signal handlers, and mach exception` >> `// handlers. By replacing the existing task exception handler, we disable gdb's mach` >> `// exception handling, while leaving the standard BSD signal handlers functional.` >> >> Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow? > > To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` > > Remaining questions: > > a) why we need `EXC_MASK_ARITHMETIC` ? > b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? > c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? > d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? Thanks for your questions Gerard. > Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). > Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? > a) why we need `EXC_MASK_ARITHMETIC` ? I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. > b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. > c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. > d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? Maybe. I don't see any value in it though, except making the code more complicated to read ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From almatvee at openjdk.java.net Wed Feb 3 22:22:39 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 3 Feb 2021 22:22:39 GMT Subject: RFR: JDK-8259927: Windows jpackage installer issues In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 14:08:13 GMT, Andy Herrick wrote: > Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2382 From martin at openjdk.java.net Wed Feb 3 22:34:40 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Wed, 3 Feb 2021 22:34:40 GMT Subject: RFR: 8260664: Phaser.arrive() memory consistency effects In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 21:55:54 GMT, Martin Buchholz wrote: > 8260664: Phaser.arrive() memory consistency effects @DougLea ------------- PR: https://git.openjdk.java.net/jdk/pull/2388 From redestad at openjdk.java.net Wed Feb 3 22:41:03 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 22:41:03 GMT Subject: RFR: 8261036: Reduce classes loaded by CleanerFactory initialization [v4] In-Reply-To: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> References: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> Message-ID: > This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Simplify comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2380/files - new: https://git.openjdk.java.net/jdk/pull/2380/files/89a16eb6..a56d9a3b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2380&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2380/head:pull/2380 PR: https://git.openjdk.java.net/jdk/pull/2380 From dl at openjdk.java.net Wed Feb 3 22:44:43 2021 From: dl at openjdk.java.net (Doug Lea) Date: Wed, 3 Feb 2021 22:44:43 GMT Subject: RFR: 8260664: Phaser.arrive() memory consistency effects In-Reply-To: References: Message-ID: <1wOQfBuGobh0eI4gCYOv5LqRrauI-R67Xj6kxW7VaEM=.db3f375e-afda-4a9d-b12c-e7f9427d23f4@github.com> On Wed, 3 Feb 2021 21:55:54 GMT, Martin Buchholz wrote: > 8260664: Phaser.arrive() memory consistency effects Marked as reviewed by dl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2388 From igraves at openjdk.java.net Wed Feb 3 22:47:09 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 3 Feb 2021 22:47:09 GMT Subject: RFR: 8261004: java.util.Formatter throws wrong exception for mismatched flags in %% conversion Message-ID: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com> Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`. ------------- Commit messages: - Changing docs to reflect behavior Changes: https://git.openjdk.java.net/jdk/pull/2389/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2389&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261004 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2389.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2389/head:pull/2389 PR: https://git.openjdk.java.net/jdk/pull/2389 From serb at openjdk.java.net Wed Feb 3 23:54:51 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 3 Feb 2021 23:54:51 GMT Subject: Integrated: 8261010: Delete the Netbeans "default" license header In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov wrote: > Trivial cleanup, the "default" license header is removed in a few components. This pull request has now been integrated. Changeset: f279ff9d Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/f279ff9d Stats: 14 lines in 3 files changed: 0 ins; 14 del; 0 mod 8261010: Delete the Netbeans "default" license header Reviewed-by: iris, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/2368 From redestad at openjdk.java.net Wed Feb 3 23:55:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 3 Feb 2021 23:55:06 GMT Subject: RFR: 8261030: Avoid loading GenerateJLIClassesHelper at runtime [v2] In-Reply-To: References: Message-ID: <6dVnPvK3opxIj0zaCs_Lc7nyO0_HrGOvMwJec3hErFI=.f64d2e08-1196-4358-bd51-7670bc3a9e1a@github.com> > This moves the tracing methods added to GenerateJLIClassesHelper in JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code meant for jlink. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove RESOLVE constants, comment the trace methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2376/files - new: https://git.openjdk.java.net/jdk/pull/2376/files/2931ef8a..5c2eff28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2376&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2376&range=00-01 Stats: 21 lines in 2 files changed: 8 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2376/head:pull/2376 PR: https://git.openjdk.java.net/jdk/pull/2376 From gziemski at openjdk.java.net Wed Feb 3 23:55:06 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:06 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:17:02 GMT, Bernhard Urban-Forster wrote: >> To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS` >> >> Remaining questions: >> >> a) why we need `EXC_MASK_ARITHMETIC` ? >> b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that? >> c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? >> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? > > Thanks for your questions Gerard. > >> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. > > That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). > >> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? > > `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? > >> a) why we need `EXC_MASK_ARITHMETIC` ? > > I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. > >> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? > > The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. > >> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? > > aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. > >> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? > > Maybe. I don't see any value in it though, except making the code more complicated to read ?? I don't like the idea of using masks on architectures that do not require them. How about something like this? `#if defined(__APPLE__)` ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` ` // exception handling, while leaving the standard BSD signal handlers functional.` ` //` ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` ` // EXC_MASK_ARITHMETIC needed by i386` ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` ` kern_return_t kr;` ` kr = task_set_exception_ports(mach_task_self(),` ` EXC_MASK_BAD_ACCESS` ` NOT_LP64(| EXC_MASK_ARITHMETIC)` ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` ` MACH_PORT_NULL,` ` EXCEPTION_STATE_IDENTITY,` ` MACHINE_THREAD_STATE);` ` ` ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` `#endif` If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 23:55:07 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:44:18 GMT, Gerard Ziemski wrote: >> Thanks for your questions Gerard. >> >>> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals. >> >> That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ). >> >>> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow? >> >> `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? >> >>> a) why we need `EXC_MASK_ARITHMETIC` ? >> >> I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here. >> >>> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that? >> >> The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`. >> >>> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well? >> >> aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases. >> >>> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`? >> >> Maybe. I don't see any value in it though, except making the code more complicated to read ?? > > I don't like the idea of using masks on architectures that do not require them. How about something like this? > > `#if defined(__APPLE__)` > ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` > ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` > ` // exception handling, while leaving the standard BSD signal handlers functional.` > ` //` > ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` > ` // EXC_MASK_ARITHMETIC needed by i386` > ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` > ` kern_return_t kr;` > ` kr = task_set_exception_ports(mach_task_self(),` > ` EXC_MASK_BAD_ACCESS` > ` NOT_LP64(| EXC_MASK_ARITHMETIC)` > ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` > ` MACH_PORT_NULL,` > ` EXCEPTION_STATE_IDENTITY,` > ` MACHINE_THREAD_STATE);` > ` ` > ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` > `#endif` > > If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. No idea how to insert spaces and make text align :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Wed Feb 3 23:55:07 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 23:13:12 GMT, Bernhard Urban-Forster wrote: >> No idea how to insert spaces and make text align :-( > > using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks > > I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: > https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 > and aarch64: > https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 > (What happened with the formatting here, ugh?) > > Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? So it should be: #if defined(__APPLE__) // lldb (gdb) installs both standard BSD signal handlers, and mach exception // handlers. By replacing the existing task exception handler, we disable lldb's mach // exception handling, while leaving the standard BSD signal handlers functional. // // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization kern_return_t kr; kr = task_set_exception_ports(mach_task_self(), EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION), MACH_PORT_NULL, EXCEPTION_STATE_IDENTITY, MACHINE_THREAD_STATE); assert(kr == KERN_SUCCESS, "could not set mach task signal handler"); #endif ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From burban at openjdk.java.net Wed Feb 3 23:55:07 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Wed, 3 Feb 2021 23:55:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:48:33 GMT, Gerard Ziemski wrote: >> I don't like the idea of using masks on architectures that do not require them. How about something like this? >> >> `#if defined(__APPLE__)` >> ` // lldb (gdb) installs both standard BSD signal handlers, and mach exception` >> ` // handlers. By replacing the existing task exception handler, we disable lldb's mach` >> ` // exception handling, while leaving the standard BSD signal handlers functional.` >> ` //` >> ` // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking` >> ` // EXC_MASK_ARITHMETIC needed by i386` >> ` // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization` >> ` kern_return_t kr;` >> ` kr = task_set_exception_ports(mach_task_self(),` >> ` EXC_MASK_BAD_ACCESS` >> ` NOT_LP64(| EXC_MASK_ARITHMETIC)` >> ` AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),` >> ` MACH_PORT_NULL,` >> ` EXCEPTION_STATE_IDENTITY,` >> ` MACHINE_THREAD_STATE);` >> ` ` >> ` assert(kr == KERN_SUCCESS, "could not set mach task signal handler");` >> `#endif` >> >> If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code. > > No idea how to insert spaces and make text align :-( using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 and aarch64: https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 (What happened with the formatting here, ugh?) Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From jwilhelm at openjdk.java.net Thu Feb 4 01:24:02 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 4 Feb 2021 01:24:02 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259794: Remove EA from JDK 16 version string starting with Initial RC promotion on Feb 04, 2021(B35) - 8260704: ParallelGC: oldgen expansion needs release-store for _end - 8260927: StringBuilder::insert is incorrect without Compact Strings - 8258378: Final nroff manpage update for JDK 16 - 8257215: JFR: Events dropped when streaming over a chunk rotation - 8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled - 8260632: Build failures after JDK-8253353 - 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop - 8260608: add a regression test for 8260370 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f025bc1d...dad835ee The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2392/files Stats: 2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod Patch: https://git.openjdk.java.net/jdk/pull/2392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2392/head:pull/2392 PR: https://git.openjdk.java.net/jdk/pull/2392 From jwilhelm at openjdk.java.net Thu Feb 4 02:09:40 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 4 Feb 2021 02:09:40 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: <9bIQlW7tZAt5i8quzTGD6Z6vHAG4-Q8-_saIecOJ4dM=.b1dacc8a-2678-417c-958b-650ff659723f@github.com> On Thu, 4 Feb 2021 01:17:48 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 9b7a8f19 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/9b7a8f19 Stats: 2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/2392 From darcy at openjdk.java.net Thu Feb 4 02:14:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 4 Feb 2021 02:14:11 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math Message-ID: Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. There is no intention at the moment to change the behavior of pow to align with IEEE 754. ------------- Commit messages: - Initial changes for JDK-8240632. Changes: https://git.openjdk.java.net/jdk/pull/2395/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240632 Stats: 223 lines in 5 files changed: 212 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2395/head:pull/2395 PR: https://git.openjdk.java.net/jdk/pull/2395 From darcy at openjdk.java.net Thu Feb 4 02:14:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 4 Feb 2021 02:14:11 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy wrote: > Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. > > Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. > > If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. > > There is no intention at the moment to change the behavior of pow to align with IEEE 754. PS After the wording for the Math class is finalized, I'll add analogous wording to the StrictMath class and run a CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/2395 From sormuras at gmail.com Thu Feb 4 07:38:10 2021 From: sormuras at gmail.com (Christian Stein) Date: Thu, 4 Feb 2021 08:38:10 +0100 Subject: Module jdk.jartool should provide jarsigner tool Message-ID: Module jdk.jartoo already provides java.util.spi.ToolProvider with sun.tools.jar.JarToolProvider. [0] Is there a reason why it does provide a JarSignerToolProvider allowing `jarsigner` to be run in-process? Perhaps too many System.exit() calls in sun/security/tools/jarsigner/Main.java? Cheers, Christian [0]: https://github.com/openjdk/jdk/blob/06b33a0ad78d1577711af22020cf5fdf25112523/src/jdk.jartool/share/classes/module-info.java#L49-L50 From mikael at openjdk.java.net Thu Feb 4 08:30:48 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 4 Feb 2021 08:30:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: >>> I wonder if this is the right choice >>> ... >>> ``` >>> OopStorageParIterPerf::~OopStorageParIterPerf() { >>> ... >>> ``` >>> >> >> The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite. >> >> I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped. >> >> I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ... are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests. >> >> Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore. >> >> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions. >> >> Thank you! > > Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Thu Feb 4 09:51:57 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 09:51:57 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 08:26:35 GMT, Mikael Vidstedt wrote: > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. it's thread-specific https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon >Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Thu Feb 4 10:17:59 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Feb 2021 10:17:59 GMT Subject: RFR: 8261149: Initial nroff manpage update for JDK 17 Message-ID: We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages. ------------- Commit messages: - 8261149: Initial nroff manpage update for JDK 17 Changes: https://git.openjdk.java.net/jdk/pull/2402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261149 Stats: 49 lines in 28 files changed: 0 ins; 21 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2402/head:pull/2402 PR: https://git.openjdk.java.net/jdk/pull/2402 From Alan.Bateman at oracle.com Thu Feb 4 10:36:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Feb 2021 10:36:14 +0000 Subject: Module jdk.jartool should provide jarsigner tool In-Reply-To: References: Message-ID: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> On 04/02/2021 07:38, Christian Stein wrote: > Module jdk.jartoo already provides java.util.spi.ToolProvider with > sun.tools.jar.JarToolProvider. [0] > > Is there a reason why it does provide a JarSignerToolProvider allowing > `jarsigner` to be run in-process? Perhaps too many System.exit() calls > in sun/security/tools/jarsigner/Main.java? > > cc'ing security-dev as that is where the jarsigner tool is maintained. This may have come up in JDK 9 but I can't find any mails in the archives. Yes, it would need a bit of refactoring so that the System.exit is only called when invoked via the launcher/main method. There are also CLI options that prompt for a password that may not be suitable for programmatic use. I'm sure Max or others on security-dev will have more to say on this. -Alan From redestad at openjdk.java.net Thu Feb 4 10:49:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 10:49:42 GMT Subject: Integrated: 8261036: Reduce classes loaded by CleanerFactory initialization In-Reply-To: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> References: <0j9dnL8orFFAL8A0g4u8mbvJVcwign4UY8KWQyEo_Z8=.49d32ab3-9779-450c-82b7-dd408218eb25@github.com> Message-ID: On Wed, 3 Feb 2021 13:21:33 GMT, Claes Redestad wrote: > This patch refactors CleanerFactory and InnocuousThread so that we need to load fewer PrivilegedActions. This slightly reduce the number of classes we always load on bootstrap, slightly reducing static and dynamic footprint (default CDS archive -4Kb). This pull request has now been integrated. Changeset: 992b5008 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/992b5008 Stats: 70 lines in 3 files changed: 35 ins; 19 del; 16 mod 8261036: Reduce classes loaded by CleanerFactory initialization Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/2380 From redestad at openjdk.java.net Thu Feb 4 10:49:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 10:49:56 GMT Subject: Integrated: 8261030: Avoid loading GenerateJLIClassesHelper at runtime In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 12:08:58 GMT, Claes Redestad wrote: > This moves the tracing methods added to GenerateJLIClassesHelper in JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code meant for jlink. This pull request has now been integrated. Changeset: 83357b11 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/83357b11 Stats: 73 lines in 4 files changed: 36 ins; 31 del; 6 mod 8261030: Avoid loading GenerateJLIClassesHelper at runtime Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2376 From raffaello.giulietti at gmail.com Thu Feb 4 11:22:43 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 4 Feb 2021 12:22:43 +0100 Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math Message-ID: <6264db5c-4d3f-b6b3-f66e-0adcb4174272@gmail.com> Hello Joe, in the javadoc of acos() I think you should replace the mathematically incorrect *
  • If the argument is {@linkplain Double#isInfinite infinite}, with something like *
  • If the argument is zero, Also, in some places pi/2 is described as pi/2, rounded, which is more open to interpretation, depending on what is meant by "rounded" (which mode? Granted, default is "to closest"), whereas in other places it is described as the value closest to pi/2 which is preferable, as it is unambiguous. Greetings Raffaello > On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy wrote: > >> Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. >> >> Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. >> >> If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. >> >> There is no intention at the moment to change the behavior of pow to align with IEEE 754. > > PS After the wording for the Math class is finalized, I'll add analogous wording to the StrictMath class and run a CSR. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2395 > From akozlov at openjdk.java.net Thu Feb 4 12:00:51 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 4 Feb 2021 12:00:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <9N0zJ8ZgY9e3yIF3IKnkdbkRu80waLyh8GHBti22DK8=.949c0612-f514-44a0-9d2b-ff9e2eb539d1@github.com> On Tue, 2 Feb 2021 22:56:55 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/runtime/stubRoutines.inline.hpp line 1: > >> 1: /* > > NOW I understand the reason for switching from include to inline-include. > Is there a reason that this change is part of this project and not extracted > into a separate RFE. That would reduce the number of files touched by > this project. Makes sense, thanks. I'll do this as JDK-8261075. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dholmes at openjdk.java.net Thu Feb 4 12:25:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Feb 2021 12:25:04 GMT Subject: RFR: 8261149: Initial nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: <63mJCmlChlanzUbpHIZVB-A5k9fpuoxB_wuWUWh4X3w=.ee0f50ac-c5c6-4e4c-9ac9-5644d752ab6a@github.com> On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote: > We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages. LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2402 From jlaskey at openjdk.java.net Thu Feb 4 12:42:00 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 4 Feb 2021 12:42:00 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v16] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - Merge branch 'master' into 8248862 - Correct range used by nextBytes - Merge branch 'master' into 8248862 - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - ... and 34 more: https://git.openjdk.java.net/jdk/compare/83357b11...1c17ad35 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=15 Stats: 13259 lines in 26 files changed: 11119 ins; 2050 del; 90 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From coleenp at openjdk.java.net Thu Feb 4 13:16:43 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Feb 2021 13:16:43 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Wed, 3 Feb 2021 19:49:30 GMT, Mandy Chung wrote: >> This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. > > src/java.base/share/native/libjava/ClassLoader.c line 291: > >> 289: } >> 290: // disallow slashes in input, change '.' to '/' >> 291: if (verifyFixClassname(clname)) { > > perhaps we should replace all use of `fixClassname` with `verifyFixClassname` and remove `fixClassname`. This suggestion makes sense to me. verifyClassName is only used once in Class.c passing false so you could remove that argument. It's hard to see how fixClassName then verifyClassname is equivalent to verifyFixClassname but verifyFixClassname makes more sense than verifyClassname. I think this return: return (p != 0 && p - name == (ptrdiff_t)length); implies a non-utf8 character was found? ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From coleenp at openjdk.java.net Thu Feb 4 13:16:41 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Feb 2021 13:16:41 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM In-Reply-To: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Wed, 3 Feb 2021 12:21:30 GMT, Claes Redestad wrote: > This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. Changes requested by coleenp (Reviewer). src/java.base/share/classes/java/lang/ClassLoader.java line 1259: > 1257: Class findBootstrapClassOrNull(String name) { > 1258: return findBootstrapClass(name); > 1259: } I'm confused why this would improve performance. Wouldn't avoiding the transition between Java to the VM be good? Or is checkName seldom false, so we're checking valid names for nothing? ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From coleenp at openjdk.java.net Thu Feb 4 13:16:44 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Feb 2021 13:16:44 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Thu, 4 Feb 2021 13:11:47 GMT, Coleen Phillimore wrote: >> src/java.base/share/native/libjava/ClassLoader.c line 291: >> >>> 289: } >>> 290: // disallow slashes in input, change '.' to '/' >>> 291: if (verifyFixClassname(clname)) { >> >> perhaps we should replace all use of `fixClassname` with `verifyFixClassname` and remove `fixClassname`. > > This suggestion makes sense to me. verifyClassName is only used once in Class.c passing false so you could remove that argument. > It's hard to see how fixClassName then verifyClassname is equivalent to verifyFixClassname but verifyFixClassname makes more sense than verifyClassname. > I think this return: > return (p != 0 && p - name == (ptrdiff_t)length); > implies a non-utf8 character was found? Actually I think replacing fixClassName with verifyFixClassname will be awkward since the latter returns a value that's not checked in all the callers of fixClassName. Maybe you could write fixClassName as: void fixClassName() { verifyFixClassName(); with some assertion it passed? } ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From redestad at openjdk.java.net Thu Feb 4 13:25:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 13:25:52 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: <5FaAQkARB-2Vg67MU55A6zFI0icKnjO5aegBSpq6cDM=.ba72b609-a85f-4424-942f-2fdd6a973e2f@github.com> On Thu, 4 Feb 2021 12:54:43 GMT, Coleen Phillimore wrote: >> This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. > > src/java.base/share/classes/java/lang/ClassLoader.java line 1259: > >> 1257: Class findBootstrapClassOrNull(String name) { >> 1258: return findBootstrapClass(name); >> 1259: } > > I'm confused why this would improve performance. Wouldn't avoiding the transition between Java to the VM be good? Or is checkName seldom false, so we're checking valid names for nothing? It's practically never false, so the checking done here is just extra work. The patch skips execution of a few thousand bytecode on startup as is, but I'm reworking it to try and get rid of the last remaining checkName use clean up the verifyFixClassName/fixClassName use to perhaps consolidate code there for a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From erikj at openjdk.java.net Thu Feb 4 14:00:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 4 Feb 2021 14:00:41 GMT Subject: RFR: 8261149: Initial nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: <51s6LyOjlruKlam24RpMwUPMgI0KXr97j0O24UQy6cs=.ebb67cbf-523e-474a-9be8-1a166d1cf70a@github.com> On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote: > We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2402 From redestad at openjdk.java.net Thu Feb 4 14:29:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 14:29:54 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names Message-ID: This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 I've not figured a good way to write a regression test, but manually verified the leak and the fix by adding a microbenchmark that triggers the leak. When run with `-XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics` there will be a section of memory of unknown origin, e.g.: - Unknown (reserved=65536KB, committed=55104KB) (mmap: reserved=65536KB, committed=55104KB) With the patch, there is no memory unaccounted for. ------------- Commit messages: - Add code used to generate the X_LONG_NAME_BYTECODE - Add micros showcasing leak - Resolve memory leak in defineClass0 Changes: https://git.openjdk.java.net/jdk/pull/2407/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2407&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261154 Stats: 88 lines in 2 files changed: 84 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2407/head:pull/2407 PR: https://git.openjdk.java.net/jdk/pull/2407 From aph at openjdk.java.net Thu Feb 4 14:30:49 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 4 Feb 2021 14:30:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 09:49:17 GMT, Vladimir Kempik wrote: > > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. > > it's thread-specific > > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon > > > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Thu Feb 4 14:40:42 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Feb 2021 14:40:42 GMT Subject: Integrated: 8261149: Initial nroff manpage update for JDK 17 In-Reply-To: References: Message-ID: <1eH5FM0wnnr5jAua6fWKyZ6De4pOpJAllvtAkBHAcyg=.954ff9dd-be33-413c-8b21-31f18b963754@github.com> On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote: > We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages. This pull request has now been integrated. Changeset: f7a6cff9 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/f7a6cff9 Stats: 49 lines in 28 files changed: 0 ins; 21 del; 28 mod 8261149: Initial nroff manpage update for JDK 17 Reviewed-by: dholmes, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2402 From vkempik at openjdk.java.net Thu Feb 4 14:43:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 14:43:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: On Thu, 4 Feb 2021 14:27:53 GMT, Andrew Haley wrote: > > > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific.. > > > > > > it's thread-specific > > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon > > > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region. > > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From herrick at openjdk.java.net Thu Feb 4 14:53:42 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 4 Feb 2021 14:53:42 GMT Subject: Integrated: JDK-8260335: [macos] Running app using relative path causes problems In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 12:43:40 GMT, Andy Herrick wrote: > Fixing FileUtils.dirname() to skip over "/.". This pull request has now been integrated. Changeset: c1dea39d Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/c1dea39d Stats: 10 lines in 1 file changed: 8 ins; 1 del; 1 mod 8260335: [macos] Running app using relative path causes problems Reviewed-by: almatvee, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/2260 From herrick at openjdk.java.net Thu Feb 4 14:55:40 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 4 Feb 2021 14:55:40 GMT Subject: RFR: JDK-8259927: Windows jpackage installer issues In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 22:19:40 GMT, Alexander Matveev wrote: >> Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. > > Marked as reviewed by almatvee (Committer). @azuev-java can you review also ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2382 From akozlov at openjdk.java.net Thu Feb 4 15:16:49 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 4 Feb 2021 15:16:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> Message-ID: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: > Out of curiosity, have you looked at the performance of the W^X state transition? Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations. >From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition. I re-did measurements with the current implementation and on consumer hardware: testJNI thrpt 25 277997000.151 ? 4095685.956 ops/s testJniNanoTime thrpt 25 17851098.010 ? 119489.599 ops/s testNanoTime thrpt 25 78007491.762 ? 628455.971 ops/s testNothing thrpt 25 1724298829.088 ? 100537565.068 ops/s testTwoStateAndWX thrpt 25 21958839.057 ? 210490.755 ops/s testWX thrpt 25 23299813.266 ? 149837.302 ops/s There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From stuefe at openjdk.java.net Thu Feb 4 15:50:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Feb 2021 15:50:41 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 14:23:56 GMT, Claes Redestad wrote: > This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 > > I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. > > E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: > > Baseline: > N = 20 Maximum resident set size (kbytes): 544860 > N = 50 Maximum resident set size (kbytes): 818532 > N = 100 Maximum resident set size (kbytes): 1388560 > Patch: > N = 20 Maximum resident set size (kbytes): 480476 > N = 50 Maximum resident set size (kbytes): 764040 > N = 100 Maximum resident set size (kbytes): 782920 Hi Cleas, looks good but why changing the the NULL comparisons? If you wanted to simplify you could completely omit the NULL checks since free(NULL) is a noop. And potentially merge the labels - where there are two - into one. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From redestad at openjdk.java.net Thu Feb 4 15:55:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 15:55:41 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 15:48:16 GMT, Thomas Stuefe wrote: >> This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 >> >> I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. >> >> E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: >> >> Baseline: >> N = 20 Maximum resident set size (kbytes): 544860 >> N = 50 Maximum resident set size (kbytes): 818532 >> N = 100 Maximum resident set size (kbytes): 1388560 >> Patch: >> N = 20 Maximum resident set size (kbytes): 480476 >> N = 50 Maximum resident set size (kbytes): 764040 >> N = 100 Maximum resident set size (kbytes): 782920 > > Hi Cleas, > > looks good but why changing the the NULL comparisons? > > If you wanted to simplify you could completely omit the NULL checks since free(NULL) is a noop. And potentially merge the labels - where there are two - into one. > > Cheers, Thomas I'm not sure every platform have always agreed free(NULL) is a noop. I suspect all the currently supported ones do, though? ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From redestad at openjdk.java.net Thu Feb 4 16:14:57 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 16:14:57 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: References: Message-ID: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> > This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 > > I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. > > E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: > > Baseline: > N = 20 Maximum resident set size (kbytes): 544860 > N = 50 Maximum resident set size (kbytes): 818532 > N = 100 Maximum resident set size (kbytes): 1388560 > N = 200 Maximum resident set size (kbytes): 2124296 > Patch: > N = 20 Maximum resident set size (kbytes): 480476 > N = 50 Maximum resident set size (kbytes): 764040 > N = 100 Maximum resident set size (kbytes): 782920 > N = 200 Maximum resident set size (kbytes): 921272 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Dial back cleanups and focus patch on the bug at hand ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2407/files - new: https://git.openjdk.java.net/jdk/pull/2407/files/972696ec..f25b5f98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2407&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2407&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2407/head:pull/2407 PR: https://git.openjdk.java.net/jdk/pull/2407 From kizune at openjdk.java.net Thu Feb 4 16:36:42 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 4 Feb 2021 16:36:42 GMT Subject: RFR: JDK-8259927: Windows jpackage installer issues In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 14:08:13 GMT, Andy Herrick wrote: > Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. Looks fine. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2382 From stuefe at openjdk.java.net Thu Feb 4 17:00:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Feb 2021 17:00:41 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 15:53:24 GMT, Claes Redestad wrote: > I'm not sure every platform have always agreed free(NULL) is a noop. I suspect all the currently supported ones do, though? Its standard behavior. Posix: https://pubs.opengroup.org/onlinepubs/009695399/functions/free.html "If ptr is a null pointer, no action shall occur. " Windows: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/free?view=msvc-160 " If memblock is NULL, the pointer is ignored and free immediately returns. " So it should be okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From redestad at openjdk.java.net Thu Feb 4 17:04:44 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Feb 2021 17:04:44 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 16:57:37 GMT, Thomas Stuefe wrote: >> I'm not sure every platform have always agreed free(NULL) is a noop. I suspect all the currently supported ones do, though? > >> I'm not sure every platform have always agreed free(NULL) is a noop. I suspect all the currently supported ones do, though? > > Its standard behavior. > > Posix: https://pubs.opengroup.org/onlinepubs/009695399/functions/free.html "If ptr is a null pointer, no action shall occur. " > Windows: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/free?view=msvc-160 " If memblock is NULL, the pointer is ignored and free immediately returns. " > > So it should be okay. Right. I dialed back the changes here since this is a bug fix that should be kept minimal. I have another change in the pipeline that will touch code here that can double down on cleaning up. ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From chegar at openjdk.java.net Thu Feb 4 17:09:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 4 Feb 2021 17:09:42 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> References: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> Message-ID: <35eRZFi6J8YBkPUYikBAkoI28JrMI92eRI-V-rzLkd8=.8d863592-f490-4125-86e0-d0729cacecc6@github.com> On Thu, 4 Feb 2021 16:14:57 GMT, Claes Redestad wrote: >> This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 >> >> I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. >> >> E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: >> >> Baseline: >> N = 20 Maximum resident set size (kbytes): 544860 >> N = 50 Maximum resident set size (kbytes): 818532 >> N = 100 Maximum resident set size (kbytes): 1388560 >> N = 200 Maximum resident set size (kbytes): 2124296 >> Patch: >> N = 20 Maximum resident set size (kbytes): 480476 >> N = 50 Maximum resident set size (kbytes): 764040 >> N = 100 Maximum resident set size (kbytes): 782920 >> N = 200 Maximum resident set size (kbytes): 921272 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Dial back cleanups and focus patch on the bug at hand LGTM. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2407 From stuefe at openjdk.java.net Thu Feb 4 17:09:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Feb 2021 17:09:43 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> References: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> Message-ID: <8Tprx7cBVlaex-VGnHcwzKqFlqMj4GflZMqUax_JFkQ=.3821bc70-fdf7-412b-8144-72c1259e58f9@github.com> On Thu, 4 Feb 2021 16:14:57 GMT, Claes Redestad wrote: >> This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 >> >> I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. >> >> E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: >> >> Baseline: >> N = 20 Maximum resident set size (kbytes): 544860 >> N = 50 Maximum resident set size (kbytes): 818532 >> N = 100 Maximum resident set size (kbytes): 1388560 >> N = 200 Maximum resident set size (kbytes): 2124296 >> Patch: >> N = 20 Maximum resident set size (kbytes): 480476 >> N = 50 Maximum resident set size (kbytes): 764040 >> N = 100 Maximum resident set size (kbytes): 782920 >> N = 200 Maximum resident set size (kbytes): 921272 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Dial back cleanups and focus patch on the bug at hand Looks good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2407 From mchung at openjdk.java.net Thu Feb 4 17:49:43 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 4 Feb 2021 17:49:43 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> References: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> Message-ID: On Thu, 4 Feb 2021 16:14:57 GMT, Claes Redestad wrote: >> This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 >> >> I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. >> >> E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: >> >> Baseline: >> N = 20 Maximum resident set size (kbytes): 544860 >> N = 50 Maximum resident set size (kbytes): 818532 >> N = 100 Maximum resident set size (kbytes): 1388560 >> N = 200 Maximum resident set size (kbytes): 2124296 >> Patch: >> N = 20 Maximum resident set size (kbytes): 480476 >> N = 50 Maximum resident set size (kbytes): 764040 >> N = 100 Maximum resident set size (kbytes): 782920 >> N = 200 Maximum resident set size (kbytes): 921272 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Dial back cleanups and focus patch on the bug at hand Looks good. Thanks for fixing this. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2407 From herrick at openjdk.java.net Thu Feb 4 17:51:41 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 4 Feb 2021 17:51:41 GMT Subject: Integrated: JDK-8259927: Windows jpackage installer issues In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 14:08:13 GMT, Andy Herrick wrote: > Remove lines in WixSourceBuilder that adds directive to rm-rf the parent dir(s) of the install-dir. These directories get removed anyway if they are empty without these lines, and should be left alone if not empty after removing the install dir itself. This pull request has now been integrated. Changeset: bdcbfa10 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/bdcbfa10 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8259927: Windows jpackage installer issues Reviewed-by: asemenyuk, almatvee, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/2382 From kravikumar at openjdk.java.net Thu Feb 4 17:51:40 2021 From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar) Date: Thu, 4 Feb 2021 17:51:40 GMT Subject: Integrated: 8260356: (tz) Upgrade time-zone data to tzdata2021a In-Reply-To: References: Message-ID: <0_Tpw4xuL-jbkLel66ymgrUl-P3Uu_Pl8kjJ7MJmEOo=.c5d43be2-756d-4029-8d9a-5b1f4421df56@github.com> On Tue, 2 Feb 2021 17:22:18 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review integrating tzdata2021a to JDK. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8260356 > > The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html > > Thanks, > Kiran This pull request has now been integrated. Changeset: d9aefa36 Author: Kiran Sidhartha Ravikumar URL: https://git.openjdk.java.net/jdk/commit/d9aefa36 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod 8260356: (tz) Upgrade time-zone data to tzdata2021a Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2359 From donraab at gmail.com Thu Feb 4 17:59:40 2021 From: donraab at gmail.com (Donald Raab) Date: Thu, 4 Feb 2021 12:59:40 -0500 Subject: RFR: 8180352: Add Stream.toList() method Message-ID: <54BCC930-4501-4584-8181-9757075E5DB3@gmail.com> I have been reading previous threads, the original bug request, and exploring the javadoc and implementation of toList() on Stream in JDK 16. I don?t want to waste time rehashing previous discussions, but I want to understand and prioritize the motivation of this change, and propose what I believe is a safer alternative name for this method based on the current implementation: Stream.toUnmodifiableList(). The original justification for Stream.toList() as described in the bug request filed in 2017 was: "It makes the coding just easier, saves some time and place.? see: https://bugs.openjdk.java.net/browse/JDK-8180352 Summarizing my interpretation of the eventual motivations for the change, over various threads (please correct as needed): 1. Convenience (easier to discover API and less code for developers to write - potential refactoring of large number of unmodifiable usages of Collectors.toList()) 2. Performance (less copying during parallel operations and pre-sizing for serial operations) 3. Unmodifiability (List result but thread-safe and usable in static contexts and as hash keys - unsafe for mutating operations) 4. Support for nulls (Inconsistent with Collectors.toUnmodifiableList() but consistent with other Stream methods) List is a mutable interface. It?s contract allows for ?conditional mutability?. A convention was established in 2014 with Collectors.toList() returning a mutable List (ArrayList). The spec in Collectors.toList() says there is no guarantee on the type, but there appears to be no appetite to undo this. The current Collectors.toList() convention was then further strengthened with the addition of Collectors.toUnmodifiableList() in Java 10 in 2018. The problem as I see it is that we are currently only looking inside of the JDK for convention. The convention of using the toList() name has existed in other libraries and application code for as long as List has been available as an interface. The problem of inconsistency of convention within the JDK itself can be argued away as a historical mistake, but harder to claim for the "established convention" in other libraries. We learned an important lesson in JDK 15 when the addition of a default isEmpty method to CharSequence broke Eclipse Collections. See this excellent blog from Stuart Marks: https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/. The Stream interface has existed for seven years now. The method toList() is a prime candidate for anyone who wanted to optimize for convenience over the past seven years. I found this default definition of toList() on the Folds interface in Cyclops: https://github.com/aol/cyclops/blob/dc26bdad0f2b8a5aa87de4aa946ed52a0dbf00de/cyclops/src/main/java/com/oath/cyclops/types/foldable/Folds.java#L99 I discovered these occurrences of toList() in the jOOQ library. https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/Collectable.java#L682 https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/SeqImpl.java#L557 Incidentally, this interface also defines toUnmodifiableList(). https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/Collectable.java#L692 jOOQ did not define it?s toList() method as a default method on Collectable, so it should not trigger the default method issue we discovered in JDK 15, but the specifications of toList() on Collectable and Stream are incompatible. Which specification should win? Eclipse Collections consistent convention in all of its interfaces is that toList returns a MutableList [1]. MutableList extends java.util.List, which is a mutable interface. The Stream.toList() method will violate the principle of least surprise for Eclipse Collections users based on long time established conventions for the the library. There may be other libraries and applications that have defined their own toList() methods to return List as well. Lastly, Craig Motlin explains the performance optimization we use for toList in our parallel implementation in his talk in 2014: https://www.infoq.com/presentations/java-streams-scala-parallel-collections/ Thanks, Don [1] Example usages of Eclipse Collections toList: // toList result is mutable for all of these usages with Eclipse Collections List list1 = mutableSet.toList(); List list2 = mutableSet.asLazy().toList(); List list3 = mutableSet.asParallel(Executors.newWorkStealingPool(), 10).toList(); List list4 = mutableSet.stream().collect(Collectors.toList()); List list5 = mutableSet.stream().collect(Collectors2.toList()); // toList result is currently unmodifiable in Stream List list6 = mutableSet.stream().toList(); From joe.darcy at oracle.com Thu Feb 4 18:28:28 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 4 Feb 2021 10:28:28 -0800 Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math In-Reply-To: <6264db5c-4d3f-b6b3-f66e-0adcb4174272@gmail.com> References: <6264db5c-4d3f-b6b3-f66e-0adcb4174272@gmail.com> Message-ID: <0ab63923-7253-ea38-eb66-88b38614b0ee@oracle.com> Hi Raffaello, Thanks for catching the spec error; fixed in a subsequent push. Cheers, -Joe On 2/4/2021 3:22 AM, Raffaello Giulietti wrote: > Hello Joe, > > in the javadoc of acos() I think you should replace the mathematically > incorrect > > ?*
  • If the argument is {@linkplain Double#isInfinite infinite}, > > with something like > > ?*
  • If the argument is zero, > > > > Also, in some places pi/2 is described as > > pi/2, rounded, > > which is more open to interpretation, depending on what is meant by > "rounded" (which mode? Granted, default is "to closest"), whereas in > other places it is described as > > the value closest to pi/2 > > which is preferable, as it is unambiguous. > > > Greetings > Raffaello > > > >> On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy wrote: >> >>> Recent revisions of the IEEE 754 floating-point standard have added >>> guidance on how typical math library methods (sin, cos, tan, etc.) >>> should behave in terms of their general quality of implementation as >>> well as on special values. >>> >>> Other than the pow methods, for the recommended operations listed by >>> IEEE 754 that the Java math library already includes, the special >>> cases that are specified by Java are the same as those specified by >>> IEEE 754, except for the pow method. IEEE 754 calls out some special >>> cases not explicitly listed in the Java specs. This changeset adds >>> those special cases to the spec and adds tests of the the special >>> cases if not already present. >>> >>> If method "Foo" already had a regression test, new cases were added >>> it it. Otherwise, a new test was added to cover the special cases of >>> several methods. >>> >>> There is no intention at the moment to change the behavior of pow to >>> align with IEEE 754. >> >> PS After the wording for the Math class is finalized, I'll add >> analogous wording to the StrictMath class and run a CSR. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/2395 >> From darcy at openjdk.java.net Thu Feb 4 18:30:57 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 4 Feb 2021 18:30:57 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math [v2] In-Reply-To: References: Message-ID: <_94F8Y_6vzkytWWm0s6CgyCfDI8DbpcqL2fScgjp6J8=.5e9e1a8e-7855-49a9-a715-5689306683ee@github.com> > Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. > > Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. > > If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. > > There is no intention at the moment to change the behavior of pow to align with IEEE 754. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Correct acos spec and fix regression test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2395/files - new: https://git.openjdk.java.net/jdk/pull/2395/files/052cfb30..efd606ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=00-01 Stats: 11 lines in 2 files changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2395/head:pull/2395 PR: https://git.openjdk.java.net/jdk/pull/2395 From prr at openjdk.java.net Thu Feb 4 18:52:59 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 4 Feb 2021 18:52:59 GMT Subject: RFR: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 [v2] In-Reply-To: References: Message-ID: <_Sr1d3wybM-jPx3BZqw8P9rKl1d2aJJuDjAVF209GUE=.72470885-320d-42ee-99da-7209d22f27d0@github.com> On Thu, 4 Feb 2021 11:42:48 GMT, Magnus Ihse Bursie wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove condition that should have been fixed as part of 8257858 > > Marked as reviewed by ihse (Reviewer). Magnus pointed out a condition that I think should have been removed in the fix for 8257858 : Remove JNF dependency from libosxsecurity/KeystoreImpl.m since its a build related change too, and I've verified that after removing it we still build, I am rolling it in here, if that's OK with folks ------------- PR: https://git.openjdk.java.net/jdk/pull/2396 From prr at openjdk.java.net Thu Feb 4 18:52:58 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 4 Feb 2021 18:52:58 GMT Subject: RFR: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 [v2] In-Reply-To: References: Message-ID: > remove un-needed disabling now JNF has gone .. Phil Race has updated the pull request incrementally with one additional commit since the last revision: Remove condition that should have been fixed as part of 8257858 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2396/files - new: https://git.openjdk.java.net/jdk/pull/2396/files/34dcbfb1..93fd193f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2396&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2396/head:pull/2396 PR: https://git.openjdk.java.net/jdk/pull/2396 From erikj at openjdk.java.net Thu Feb 4 19:47:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 4 Feb 2021 19:47:46 GMT Subject: RFR: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 [v2] In-Reply-To: References: Message-ID: <_uhj_JtAa8VXS21J9dBIJjcJ2q_OX_y21dxNeihMjqM=.d0559051-659c-4a5a-b076-5b7e2fb87dac@github.com> On Thu, 4 Feb 2021 18:52:58 GMT, Phil Race wrote: >> remove un-needed disabling now JNF has gone .. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > Remove condition that should have been fixed as part of 8257858 Looks good to me. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2396 From prr at openjdk.java.net Thu Feb 4 21:04:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 4 Feb 2021 21:04:41 GMT Subject: Integrated: 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 02:32:31 GMT, Phil Race wrote: > remove un-needed disabling now JNF has gone .. This pull request has now been integrated. Changeset: 3bb6a3d2 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/3bb6a3d2 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod 8261109: [macOS] Remove disabled warning for JNF in make/autoconf/flags-cflags.m4 Reviewed-by: serb, ihse, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/2396 From vkempik at openjdk.java.net Thu Feb 4 21:53:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 4 Feb 2021 21:53:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> References: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com> <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com> Message-ID: On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov wrote: >> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?). > >> Out of curiosity, have you looked at the performance of the W^X state transition? > > Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations. > > From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition. > I re-did measurements with the current implementation and on consumer hardware: > > testJNI thrpt 25 277997000.151 ? 4095685.956 ops/s > testJniNanoTime thrpt 25 17851098.010 ? 119489.599 ops/s > testNanoTime thrpt 25 78007491.762 ? 628455.971 ops/s > testNothing thrpt 25 1724298829.088 ? 100537565.068 ops/s > testTwoStateAndWX thrpt 25 21958839.057 ? 210490.755 ops/s > testWX thrpt 25 23299813.266 ? 149837.302 ops/s > > There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry. > _Mailing list message from [erik.joelsson at oracle.com](mailto:erik.joelsson at oracle.com) on [2d-dev](mailto:2d-dev at openjdk.java.net):_ > > On 2021-01-26 04:44, Magnus Ihse Bursie wrote: > > > On 2021-01-26 13:09, Vladimir Kempik wrote: > > > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward > > > wrote: > > > > AIUI, the configure line needs passing a prebuilt > > > > JavaNativeFoundation framework > > > > ie: > > > > `--with-extra-ldflags='-F > > > > /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'` > > > > Otherwise there will be missing _JNFNative* functions. > > > > Is this the long term plan? Or will eventually the required code be > > > > moved into JDK and/or the xcode one automatically get picked up by > > > > the configure scripts? > > > > There is ongoing work by P. Race to eliminate dependence on JNF at all > > > > How far has that work come? Otherwise the logic should be added to > > > > configure to look for this framework automatically, and provide a way > > > > to override it/set it if not found. > > > > > > I don't think it's OK to publish a new port that cannot build > > out-of-the-box without hacks like this. > > My understanding is that Apple chose to not provide JNF for aarch64, so > if you want to build OpenJDK, you first need to build JNF yourself (it's > available in github). Phil is working on removing this dependency > completely, which will solve this issue [1]. > > In the meantime, I don't think we should rely on finding JNF in > unsupported locations inside Xcode. Could we wait with integrating this > port until it can be built without such hacks? If not, then adding > something in the documentation on how to get a working JNF would at > least be needed. > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8257852 This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. J2Demo works fine as example. This can be checked if one merges pull/2200 branch into his local copy of master branch. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:01:51 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:01:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194: > 192: // may get turned off by -fomit-frame-pointer. > 193: frame os::get_sender_for_C_frame(frame* fr) { > 194: return frame(fr->link(), fr->link(), fr->sender_pc()); Why is it return frame(fr->link(), fr->link(), fr->sender_pc()); and not return frame(fr->sender_sp(), fr->link(), fr->sender_pc()); like in the bsd-x86 counter part? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:18:49 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:18:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 291: > 289: bool is_unsafe_arraycopy = (thread->doing_unsafe_access() && UnsafeCopyMemory::contains_pc(pc)); > 290: if ((nm != NULL && nm->has_unsafe_access()) || is_unsafe_arraycopy) { > 291: address next_pc = pc + NativeCall::instruction_size; Replace address next_pc = pc + NativeCall::instruction_size; with address next_pc = Assembler::locate_next_instruction(pc); there is at least one other place that needs it. src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322: > 320: #ifdef __APPLE__ > 321: } else if (sig == SIGFPE && info->si_code == FPE_NOOP) { > 322: Unimplemented(); Is there a follow up issue for this? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:22:48 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:22:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 198: > 196: > 197: NOINLINE frame os::current_frame() { > 198: intptr_t *fp = *(intptr_t **)__builtin_frame_address(0); In the bsd_x86 counter part we initialize `fp` to `_get_previous_fp()` - do we need to implement it on aarch64 as well (and using address 0 is just a temp workaround) or is it doing the right thing here? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:36:49 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:36:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237: > 235: os::Posix::ucontext_set_pc(uc, StubRoutines::continuation_for_safefetch_fault(pc)); > 236: return true; > 237: } Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need it here again? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Thu Feb 4 22:44:47 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:44:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <5xcTYtv5IrRdAkhPa6uG0C__8L6IsXKQOCsAaeha0vk=.217371e5-85a4-4b62-a885-5236a94cd242@github.com> On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302: > 300: const uint64_t *detail_msg_ptr > 301: = (uint64_t*)(pc + NativeInstruction::instruction_size); > 302: const char *detail_msg = (const char *)*detail_msg_ptr; Where is `detail_msg` used? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From igraves at openjdk.java.net Thu Feb 4 22:49:50 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 4 Feb 2021 22:49:50 GMT Subject: RFR: 8261096: Convert jlink tool to use Stream.toList() Message-ID: A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559). This is an enhancement to update jlink's usage of `Collections.toList()` to `Stream.toList()`. ------------- Commit messages: - Converting jlink usage of Collections.toList() to Stream.toList Changes: https://git.openjdk.java.net/jdk/pull/2416/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2416&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261096 Stats: 18 lines in 8 files changed: 0 ins; 5 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2416/head:pull/2416 PR: https://git.openjdk.java.net/jdk/pull/2416 From gziemski at openjdk.java.net Thu Feb 4 22:51:50 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 22:51:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); > 296: } > 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { Can we add a comment here describing what this case means? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From naoto at openjdk.java.net Thu Feb 4 22:54:51 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 4 Feb 2021 22:54:51 GMT Subject: RFR: 8261179: Norwegian =?UTF-8?B?Qm9rbcOlbA==?= Locale fallback issue Message-ID: Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order. [1] https://unicode-org.atlassian.net/browse/CLDR-2698 ------------- Commit messages: - 8261179: Norwegian Bokm?l Locale fallback issue Changes: https://git.openjdk.java.net/jdk/pull/2414/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2414&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261179 Stats: 43 lines in 2 files changed: 22 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2414.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2414/head:pull/2414 PR: https://git.openjdk.java.net/jdk/pull/2414 From gziemski at openjdk.java.net Thu Feb 4 23:08:50 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 4 Feb 2021 23:08:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. ------------- Changes requested by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/2200 From joehw at openjdk.java.net Fri Feb 5 01:24:40 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 5 Feb 2021 01:24:40 GMT Subject: RFR: 8261179: Norwegian =?UTF-8?B?Qm9rbcOlbA==?= Locale fallback issue In-Reply-To: References: Message-ID: <1YfjO2GD2mVWgOf9c_Atmtu0qHmp8Ynp-qQw3Gi5J_g=.ea3f1b78-a552-40a6-bb1a-94a36117ebd1@github.com> On Thu, 4 Feb 2021 22:17:12 GMT, Naoto Sato wrote: > Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order. > > [1] https://unicode-org.atlassian.net/browse/CLDR-2698 Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2414 From coleenp at openjdk.java.net Fri Feb 5 02:12:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Feb 2021 02:12:55 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2] In-Reply-To: References: Message-ID: > This change does not call up to Java for checkPackageAccess if the security manager is NULL, but still saves the protection domain in the pd_set for that dictionary entry. If the option -Djava.security.manager=disallow is set, that means that there will never be a security manager and the JVM code can avoid saving the protection domains completely. > See the two functions java_lang_System::has_security_manager() and java_lang_System::allow_security_manager() for details. > Also deleted ProtectionDomainVerification because there's no use for this option. > > Tested with tier1 hotspot, jdk and langtools. > and tier2-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment and read NEVER field from System ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2410/files - new: https://git.openjdk.java.net/jdk/pull/2410/files/19ddd066..296d0adb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=00-01 Stats: 25 lines in 3 files changed: 17 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2410/head:pull/2410 PR: https://git.openjdk.java.net/jdk/pull/2410 From coleenp at openjdk.java.net Fri Feb 5 02:33:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Feb 2021 02:33:48 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 01:45:58 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment and read NEVER field from System > > src/hotspot/share/classfile/dictionary.cpp line 145: > >> 143: #ifdef ASSERT >> 144: if (protection_domain == instance_klass()->protection_domain()) { >> 145: MutexLocker ml(ProtectionDomainSet_lock, Mutex::_no_safepoint_check_flag); > > By splitting the lock scope into two blocks you have lost the atomicity of the entire action in a debug build, and now you check a potentially different pd_set(). If the dictionary entry's class matches the protection domain, then it should never be added to the pd_set list. So it doesn't need to be locked to check that. It doesn't need atomicity. > src/hotspot/share/classfile/javaClasses.cpp line 4406: > >> 4404: } >> 4405: >> 4406: // This field means that a security manager is never installed so we can completely > > This field tells you whether a SM can be installed, and if not then you can completely ... updated with "we" > src/hotspot/share/classfile/systemDictionary.cpp line 503: > >> 501: } else { >> 502: log_debug(protectiondomain)("granted"); >> 503: } > > Did you intend leaving this in? Yes, why not? It's very useful in logging. > test/hotspot/jtreg/runtime/logging/ProtectionDomainVerificationTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. > > 2021 :) I had a bug in my fix-copyrights script. > test/hotspot/jtreg/runtime/logging/ProtectionDomainVerificationTest.java line 47: > >> 45: .shouldContain("[protectiondomain] Checking package access") >> 46: .shouldContain("[protectiondomain] pd set count = #") >> 47: .shouldHaveExitValue(0); > > Minor nit: checking the exit value first can be more informative in case of a crash. The patterns I see have that last. (?) ------------- PR: https://git.openjdk.java.net/jdk/pull/2410 From coleenp at openjdk.java.net Fri Feb 5 02:37:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Feb 2021 02:37:54 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3] In-Reply-To: References: Message-ID: > This change does not call up to Java for checkPackageAccess if the security manager is NULL, but still saves the protection domain in the pd_set for that dictionary entry. If the option -Djava.security.manager=disallow is set, that means that there will never be a security manager and the JVM code can avoid saving the protection domains completely. > See the two functions java_lang_System::has_security_manager() and java_lang_System::allow_security_manager() for details. > Also deleted ProtectionDomainVerification because there's no use for this option. > > Tested with tier1 hotspot, jdk and langtools. > and tier2-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments and copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2410/files - new: https://git.openjdk.java.net/jdk/pull/2410/files/296d0adb..7a2a3617 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2410&range=01-02 Stats: 14 lines in 2 files changed: 3 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2410/head:pull/2410 PR: https://git.openjdk.java.net/jdk/pull/2410 From dholmes at openjdk.java.net Fri Feb 5 03:05:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Feb 2021 03:05:44 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 02:37:54 GMT, Coleen Phillimore wrote: >> This change does not call up to Java for checkPackageAccess if the security manager is NULL, but still saves the protection domain in the pd_set for that dictionary entry. If the option -Djava.security.manager=disallow is set, that means that there will never be a security manager and the JVM code can avoid saving the protection domains completely. >> See the two functions java_lang_System::has_security_manager() and java_lang_System::allow_security_manager() for details. >> Also deleted ProtectionDomainVerification because there's no use for this option. >> >> Tested with tier1 hotspot, jdk and langtools. >> and tier2-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments and copyright. Some comments remain confusing. Thanks, David src/hotspot/share/classfile/javaClasses.cpp line 4415: > 4413: > 4414: // This field means that a security manager can be installed so we still have to > 4415: // populate the ProtectionDomainCacheTable. No this field returns the installed SM if any. It doesn't tell you anything about whether you can install a SM or not (though obviously if non-NULL then you could). src/java.base/share/classes/java/lang/System.java line 163: > 161: > 162: // indicates if a security manager is possible > 163: // @implNote The HotSpot JVM hardcodes the value of NEVER. You don't need this if the VM reads the value of NEVER. ------------- PR: https://git.openjdk.java.net/jdk/pull/2410 From dholmes at openjdk.java.net Fri Feb 5 03:11:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Feb 2021 03:11:42 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 02:25:15 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/dictionary.cpp line 145: >> >>> 143: #ifdef ASSERT >>> 144: if (protection_domain == instance_klass()->protection_domain()) { >>> 145: MutexLocker ml(ProtectionDomainSet_lock, Mutex::_no_safepoint_check_flag); >> >> By splitting the lock scope into two blocks you have lost the atomicity of the entire action in a debug build, and now you check a potentially different pd_set(). > > If the dictionary entry's class matches the protection domain, then it should never be added to the pd_set list. So it doesn't need to be locked to check that. It doesn't need atomicity. I missed the re-check at line 163 means we are going to return immediately after we execute the debug code. ------------- PR: https://git.openjdk.java.net/jdk/pull/2410 From dholmes at openjdk.java.net Fri Feb 5 03:17:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Feb 2021 03:17:44 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 02:28:31 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 503: >> >>> 501: } else { >>> 502: log_debug(protectiondomain)("granted"); >>> 503: } >> >> Did you intend leaving this in? > > Yes, why not? It's very useful in logging. There's no context for this final bit out of output. It could appear many lines after the earlier logging, and unless there is some locking around all this, could be interleaved with different PD checks. It seems to me that all the logging could occur after the Java call and include the success/failure. It could also include whether the check trivially succeeded due to there being no SM. ------------- PR: https://git.openjdk.java.net/jdk/pull/2410 From gziemski at openjdk.java.net Fri Feb 5 05:03:54 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 05:03:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403: > 401: } > 402: > 403: return false; // Mute compiler Is this comment needed? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420: > 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K; > 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K; > 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K; Those are slightly larger than their x86_64 counter parts. Are they conservative/aggressive values? How did we arrive at those? src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 652: > 650: > 651: void os::setup_fpu() { > 652: } Is there really nothing to do here, or does still need to be implemented? A clarification comment here would help/. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From gziemski at openjdk.java.net Fri Feb 5 05:03:53 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 05:03:53 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:09:58 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: > >> 361: address pc = os::Posix::ucontext_get_pc(uc); >> 362: >> 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means > > Is this TODO going to be resolved by this port? Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 374: > >> 372: >> 373: last_addr = (address) -1; >> 374: } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means > > Is this TODO going to be resolved by this port? Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Fri Feb 5 07:58:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 5 Feb 2021 07:58:41 GMT Subject: RFR: 8261096: Convert jlink tool to use Stream.toList() In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 22:45:10 GMT, Ian Graves wrote: > A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559). This is an enhancement to update jlink's usage of `Collections.toList()` to `Stream.toList()`. Looks fine, if any of these lists were being modified then I would expect the build and/or tests to fail. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2416 From cushon at openjdk.java.net Fri Feb 5 08:15:01 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 5 Feb 2021 08:15:01 GMT Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation type In-Reply-To: <-JJzDCYUAtnxPkJJ67a45ehz6SN8FEJn6vubpKwThTQ=.7c25c4c9-fbf8-42ea-8690-2cc40b56223d@github.com> References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com> <-JJzDCYUAtnxPkJJ67a45ehz6SN8FEJn6vubpKwThTQ=.7c25c4c9-fbf8-42ea-8690-2cc40b56223d@github.com> Message-ID: On Thu, 4 Feb 2021 21:04:51 GMT, Liam Miller-Cushon wrote: >> Thanks, I was missing context here. I now realize this patch is fixing a bug related to [JDK-8254023](https://bugs.openjdk.java.net/browse/JDK-8254023)--when the handling of annotations without `@Target` was updated to allow them to be applied to module declarations, the handling of repeatable annotations without `@Target` should also have been updated. I filed a new bug for the sub-issue that this patch is fixing, and will update it accordingly in a minute: https://bugs.openjdk.java.net/browse/JDK-8261088 >> >> I'm also happy to help with any work to be done on the larger question of interpreting `@Target`-less annotations as applicable to type contexts, if there's agreement about what to do there. > > I spun the original change that related specifically to repeatable annotations and `@Target(MODULE)` out into https://github.com/openjdk/jdk/pull/2412 and filed corresponding CSR [JDK-8261181](https://bugs.openjdk.java.net/browse/JDK-8261181). > > I will look at updating this review to actually implement the change to make no-`@Target` annotations applicable to all contexts next. I pushed an initial implementation of a fix to make no-`@Target` annotation applicable in all contexts, including type contexts. I have updated affected tier 1 langtools tests, which provides some signal about the compatibility impact. That also uncovered a couple of bugs: one issue where javadoc isn't escaping type annotations in html ([JDK-8261203](https://bugs.openjdk.java.net/browse/JDK-8261203)), and a crash with intersection types and LVTI ([JDK-8261205](https://bugs.openjdk.java.net/browse/JDK-8261205)). ------------- PR: https://git.openjdk.java.net/jdk/pull/2303 From cushon at openjdk.java.net Fri Feb 5 08:15:00 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 5 Feb 2021 08:15:00 GMT Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation type [v2] In-Reply-To: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> Message-ID: > Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations. Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8231436: Fix the applicability of a no- at Target annotation type ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2303/files - new: https://git.openjdk.java.net/jdk/pull/2303/files/b0d6abbc..7e1c404d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2303&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2303&range=00-01 Stats: 191 lines in 36 files changed: 115 ins; 36 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/2303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2303/head:pull/2303 PR: https://git.openjdk.java.net/jdk/pull/2303 From redestad at openjdk.java.net Fri Feb 5 09:01:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 5 Feb 2021 09:01:41 GMT Subject: RFR: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names [v2] In-Reply-To: <8Tprx7cBVlaex-VGnHcwzKqFlqMj4GflZMqUax_JFkQ=.3821bc70-fdf7-412b-8144-72c1259e58f9@github.com> References: <1ZDUvVPQBu3TDosSok5yCRuKk4VpVAluX55RPv6WwoY=.47ef8fa6-431d-4d69-a5cf-d882aa3bd758@github.com> <8Tprx7cBVlaex-VGnHcwzKqFlqMj4GflZMqUax_JFkQ=.3821bc70-fdf7-412b-8144-72c1259e58f9@github.com> Message-ID: On Thu, 4 Feb 2021 17:07:01 GMT, Thomas Stuefe wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Dial back cleanups and focus patch on the bug at hand > > Looks good! @tstuefe, @ChrisHegarty, @mlchung - thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From redestad at openjdk.java.net Fri Feb 5 09:01:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 5 Feb 2021 09:01:42 GMT Subject: Integrated: 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 14:23:56 GMT, Claes Redestad wrote: > This patch resolves a potential memory leak in Java_java_lang_ClassLoader_defineClass0 > > I've not figured a good way to write a regression test. A crude way to manually verify the leak and the fix is provided by the added microbenchmark that triggers the malloc in ClassLoader.c and the associated leak. > > E.g., running this with `/usr/bin/time -v $BUILD_DIR/images/jdk/bin/java -Xmx256m -jar $BUILD_DIR/images/test/micro/benchmarks.jar LookupDef.*WeakClass.loadLong -f 0 -i N | grep "Maximum resident set"` yields: > > Baseline: > N = 20 Maximum resident set size (kbytes): 544860 > N = 50 Maximum resident set size (kbytes): 818532 > N = 100 Maximum resident set size (kbytes): 1388560 > N = 200 Maximum resident set size (kbytes): 2124296 > Patch: > N = 20 Maximum resident set size (kbytes): 480476 > N = 50 Maximum resident set size (kbytes): 764040 > N = 100 Maximum resident set size (kbytes): 782920 > N = 200 Maximum resident set size (kbytes): 921272 This pull request has now been integrated. Changeset: 07918995 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/07918995 Stats: 79 lines in 2 files changed: 79 ins; 0 del; 0 mod 8261154: Memory leak in Java_java_lang_ClassLoader_defineClass0 with long class names Reviewed-by: stuefe, chegar, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2407 From ihse at openjdk.java.net Fri Feb 5 09:51:54 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 09:51:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > make/autoconf/flags.m4 line 140: > >> 138: else >> 139: MACOSX_VERSION_MIN=10.12.0 >> 140: fi > > Not something that needs to be addressed here, but these changes > illustrate that our collective use of macOSX/MACOSX/MacOSX names > are tied to the fact that the macOS major version number was at 10 > for a very long time. > > @magicus - Do we have an RFE to rename MACOSX or are we sticking > with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? @dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort. If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it. > make/common/NativeCompilation.gmk line 1178: > >> 1176: endif >> 1177: # This only works if the openjdk_codesign identity is present on the system. Let >> 1178: # silently fail otherwise. > > Might want to add a comment here: > # The '-f' option will replace an existing signature if one exists. We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Fri Feb 5 09:51:52 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 5 Feb 2021 09:51:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 23:05:56 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. > > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. > > I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. Got it, OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From michaelm at openjdk.java.net Fri Feb 5 09:58:55 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 5 Feb 2021 09:58:55 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets Message-ID: Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. Thanks, Michael ------------- Commit messages: - update - update - update - update - update after Alan's first review - Merge branch 'master' into 8252971-socket-attributes - test update - initial fix for review Changes: https://git.openjdk.java.net/jdk/pull/2424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252971 Stats: 241 lines in 8 files changed: 226 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From ihse at openjdk.java.net Fri Feb 5 10:00:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 10:00:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: > > - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos > - Add comments to WX transitions > > + minor change of placements > - Use macro conditionals instead of empty functions > - Add W^X to tests > - Do not require known W^X state > - Revert w^x in gtests Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From ihse at openjdk.java.net Fri Feb 5 10:00:50 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Feb 2021 10:00:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote: >> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments. > >> > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch. >> >> I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment. > > Got it, OK. > This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. @VladimirKempik I agree. That concludes the build issues with this PR. So from a build perspective, this is now good to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dfuchs at openjdk.java.net Fri Feb 5 12:06:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 5 Feb 2021 12:06:44 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael test/jdk/java/nio/channels/unixdomain/FileAttributes.java line 82: > 80: > 81: // Check deletion > 82: assertTrue(f.delete(), "File.delete failed"); What happens to the socket if you delete the file before closing the socket? Isn't that going to cause trouble? ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Fri Feb 5 12:10:42 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 5 Feb 2021 12:10:42 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 12:03:30 GMT, Daniel Fuchs wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > test/jdk/java/nio/channels/unixdomain/FileAttributes.java line 82: > >> 80: >> 81: // Check deletion >> 82: assertTrue(f.delete(), "File.delete failed"); > > What happens to the socket if you delete the file before closing the socket? Isn't that going to cause trouble? Deleting the file prevents new connections from being accepted, but doesn't cause any problems for the channel itself. Since the test is finished at that point I don't think there is a problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From akozlov at openjdk.java.net Fri Feb 5 12:29:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 12:29:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > Marked as reviewed by ihse (Reviewer). > I haven't got a MacOS AArch64 system right now. Is it possible to > enable W^X in Linux in order to kick the tyres? I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dfuchs at openjdk.java.net Fri Feb 5 12:40:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 5 Feb 2021 12:40:40 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets In-Reply-To: References: Message-ID: <8o3-JUwwHvgrxB13p7pajzQeBBzu9WwoU-4__Ys-YNk=.9f963011-7352-4a6d-be81-2dd0f0669c8e@github.com> On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael This look reasonable to me - but I am not an expert on windows native APIs. The test seems good and comprehensive though - I particularly like the fact that it tests for `isDirectory`, `isRegularFile`, `isSymlink` and `isOther`, and that it verifies that the socket file can be deleted in the end. Please wait for a second opinion before integrating. Also consider whether to write a release note - since you re-enabling support for some versions of Windows for which it was disabled. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2424 From akozlov at openjdk.java.net Fri Feb 5 13:01:05 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 13:01:05 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v11] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Cleanup SA changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/80827176..8652d21d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=09-10 Stats: 11 lines in 1 file changed: 3 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 13:01:06 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 13:01:06 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer wrote: >> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin > > src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702: > >> 700: primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL); >> 701: >> 702: #undef REG_INDEX > > I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value. We've merged two implementations of SA, this change slipped in. I've cleaned this up. Thanks for noticing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From nikhilnanivadekar at gmail.com Fri Feb 5 14:02:35 2021 From: nikhilnanivadekar at gmail.com (Nikhil Nanivadekar) Date: Fri, 5 Feb 2021 08:02:35 -0600 Subject: RFR: 8180352: Add Stream.toList() method In-Reply-To: <54BCC930-4501-4584-8181-9757075E5DB3@gmail.com> References: <54BCC930-4501-4584-8181-9757075E5DB3@gmail.com> Message-ID: Thanks Don for a detailed email. I concur with your reservations and worries. My biggest worry is that the unmodifiable nature of return type while giving no compile time indications leave issues to be encountered at runtime. Now it is up for argument that there should be tests which fail and these failing tests should catch these issues. Additionally, developers should read the Javadoc and understand the implications. But that happens in a perfect world I would say. Similar comments are shared here as well: https://bugs.openjdk.java.net/browse/JDK-8260559 I am a bit curious how IDEs (Eclipse, IntelliJ, Netbeans) are going to handle it? Are they going to give an auto-fix for replacement? That might be misleading as well. Thoughts? On Thu, Feb 4, 2021 at 12:00 PM Donald Raab wrote: > I have been reading previous threads, the original bug request, and > exploring the javadoc and implementation of toList() on Stream in JDK 16. I > don?t want to waste time rehashing previous discussions, but I want to > understand and prioritize the motivation of this change, and propose what I > believe is a safer alternative name for this method based on the current > implementation: Stream.toUnmodifiableList(). > > > The original justification for Stream.toList() as described in the bug > request filed in 2017 was: "It makes the coding just easier, saves some > time and place.? > > see: https://bugs.openjdk.java.net/browse/JDK-8180352 > > > Summarizing my interpretation of the eventual motivations for the change, > over various threads (please correct as needed): > > 1. Convenience (easier to discover API and less code for developers to > write - potential refactoring of large number of unmodifiable usages of > Collectors.toList()) > 2. Performance (less copying during parallel operations and pre-sizing for > serial operations) > 3. Unmodifiability (List result but thread-safe and usable in static > contexts and as hash keys - unsafe for mutating operations) > 4. Support for nulls (Inconsistent with Collectors.toUnmodifiableList() > but consistent with other Stream methods) > > > List is a mutable interface. It?s contract allows for ?conditional > mutability?. A convention was established in 2014 with Collectors.toList() > returning a mutable List (ArrayList). The spec in Collectors.toList() says > there is no guarantee on the type, but there appears to be no appetite to > undo this. The current Collectors.toList() convention was then further > strengthened with the addition of Collectors.toUnmodifiableList() in Java > 10 in 2018. > > > The problem as I see it is that we are currently only looking inside of > the JDK for convention. The convention of using the toList() name has > existed in other libraries and application code for as long as List has > been available as an interface. The problem of inconsistency of convention > within the JDK itself can be argued away as a historical mistake, but > harder to claim for the "established convention" in other libraries. > > > We learned an important lesson in JDK 15 when the addition of a default > isEmpty method to CharSequence broke Eclipse Collections. See this > excellent blog from Stuart Marks: > https://stuartmarks.wordpress.com/2020/09/22/incompatibilities-with-jdk-15-charsequence-isempty/ > . > > > The Stream interface has existed for seven years now. The method toList() > is a prime candidate for anyone who wanted to optimize for convenience over > the past seven years. > > > I found this default definition of toList() on the Folds interface in > Cyclops: > > https://github.com/aol/cyclops/blob/dc26bdad0f2b8a5aa87de4aa946ed52a0dbf00de/cyclops/src/main/java/com/oath/cyclops/types/foldable/Folds.java#L99 > > > I discovered these occurrences of toList() in the jOOQ library. > > https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/Collectable.java#L682 > > https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/SeqImpl.java#L557 > > > Incidentally, this interface also defines toUnmodifiableList(). > > https://github.com/jOOQ/jOOL/blob/main/jOOL/src/main/java/org/jooq/lambda/Collectable.java#L692 > > > jOOQ did not define it?s toList() method as a default method on > Collectable, so it should not trigger the default method issue we > discovered in JDK 15, but the specifications of toList() on Collectable and > Stream are incompatible. Which specification should win? > > > Eclipse Collections consistent convention in all of its interfaces is that > toList returns a MutableList [1]. MutableList extends java.util.List, which > is a mutable interface. The Stream.toList() method will violate the > principle of least surprise for Eclipse Collections users based on long > time established conventions for the the library. There may be other > libraries and applications that have defined their own toList() methods to > return List as well. > > > Lastly, Craig Motlin explains the performance optimization we use for > toList in our parallel implementation in his talk in 2014: > https://www.infoq.com/presentations/java-streams-scala-parallel-collections/ > > > Thanks, > Don > > > [1] Example usages of Eclipse Collections toList: > > > // toList result is mutable for all of these usages with Eclipse > Collections > List list1 = mutableSet.toList(); > List list2 = mutableSet.asLazy().toList(); > List list3 = mutableSet.asParallel(Executors.newWorkStealingPool(), > 10).toList(); > List list4 = mutableSet.stream().collect(Collectors.toList()); > List list5 = mutableSet.stream().collect(Collectors2.toList()); > > > // toList result is currently unmodifiable in Stream > List list6 = mutableSet.stream().toList(); From asemenyuk at openjdk.java.net Fri Feb 5 14:47:24 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 5 Feb 2021 14:47:24 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v4] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: - 8254702: jpackage app launcher crashes on CentOS - 8254702: jpackage app launcher crashes on CentOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2320/files - new: https://git.openjdk.java.net/jdk/pull/2320/files/91744255..b6c62a2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=02-03 Stats: 49 lines in 10 files changed: 26 ins; 11 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From asemenyuk at openjdk.java.net Fri Feb 5 14:53:26 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 5 Feb 2021 14:53:26 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v5] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: 8254702: jpackage app launcher crashes on CentOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2320/files - new: https://git.openjdk.java.net/jdk/pull/2320/files/b6c62a2a..b2413570 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From daniel.daugherty at oracle.com Fri Feb 5 15:05:25 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 5 Feb 2021 10:05:25 -0500 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <18c74331-6056-405f-1207-e62787f34830@oracle.com> On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote: > On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote: > >>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> support macos_aarch64 in hsdis >> make/autoconf/flags.m4 line 140: >> >>> 138: else >>> 139: MACOSX_VERSION_MIN=10.12.0 >>> 140: fi >> Not something that needs to be addressed here, but these changes >> illustrate that our collective use of macOSX/MACOSX/MacOSX names >> are tied to the fact that the macOS major version number was at 10 >> for a very long time. >> >> @magicus - Do we have an RFE to rename MACOSX or are we sticking >> with it and evolving our interpretation of the 'X' from '10' to */splat/asterik? > @dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort. > > If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it. > >> make/common/NativeCompilation.gmk line 1178: >> >>> 1176: endif >>> 1177: # This only works if the openjdk_codesign identity is present on the system. Let >>> 1178: # silently fail otherwise. >> Might want to add a comment here: >> # The '-f' option will replace an existing signature if one exists. > We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 @magicus - I'm good with both of these answers. I personally like 'macosx'. Dan From brian.goetz at oracle.com Fri Feb 5 15:27:49 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 5 Feb 2021 10:27:49 -0500 Subject: RFR: 8180352: Add Stream.toList() method In-Reply-To: <54BCC930-4501-4584-8181-9757075E5DB3@gmail.com> References: <54BCC930-4501-4584-8181-9757075E5DB3@gmail.com> Message-ID: > I have been reading previous threads, the original bug request, and exploring the javadoc and implementation of toList() on Stream in JDK 16. I don?t want to waste time rehashing previous discussions, but I want to understand and prioritize the motivation of this change, and propose what I believe is a safer alternative name for this method based on the current implementation: Stream.toUnmodifiableList(). Big +1 to "let's not rehash previous discussions, but help us understand the motivation."? Stewarding the core libraries is a complex task, and there are rarely hard-and-fast rules for doing the Right Thing. Your question seems to have two main aspects: ?- Why this method, why not others, and why now ?- Why take such a strong anti-mutability position with this method The desire for a Stream::toList method has a long history; when we first did streams, it was one of the first convenience methods to be "requested".? We resisted then, for good reasons, but we knew this saga was not over. "Convenience" methods are a constant challenge in the JDK.? On the one hand, they are, well, convenient, and we want Java to be easy and pleasant to program in.? On the other, the number of potentially-useful imaginable convenience methods is infinite, and the widespread perception is that they are so easy, that all that is needed is for someone to propose the idea.? (The (admittedly soft) criteria we use for judging whether a convenience method meets the bar is an interesting one, which we can have separately.) There are basically two stable points with respect to convenience methods in API design; zero tolerance, and "don't worry, be happy". In the former, the methods of an API are like a basis (ideally, an orthonormal one) of a vector space; the minimum number of API points from which you can derive all possible usages.? At the other extreme, every reasonable combination of methods gets its own special form of expression.? Of course, both are extremes (Stream::count and IntStream::sum are conveniences for reduce, and even Haskell's Monad has multiple ways to represent bind), but APIs tend to align themselves in one direction or another.? And, as the JDK APIs go, Streams treats sparsity and orthogonality as virtues to be striven for. Eclipse Collections chooses a different (and also valid!) philosophy: completeness, and it walks the walk.? (Having 81 (template-generated) implementations of HashMap is proof.) Similarly, Tagir's StreamEx is an example of an extension to Stream that takes the other approach.? And both are great!? But also, they are not how the JDK rolls.? Which is fine; it's a big ecosystem, and there's room for multiple philosophies, and each can find its fans and detractors. The calls for a convenience for Stream::toList have come pretty much continuously since we first resisted it (but, we knew even then that if we had a lifetime budget for just one convenience method, it would end up being toList.)? We knew then that there would be questions to ask about what the ideal dial settings would be for toList, and were not yet ready to confront the question, nor did we want to add fuel to the demands for more convenience methods ("No toSet?? Inconsistent!") When an API is new, and all things are possible, we tend to be in "imagine everything we could put into it" mode, and streams was no different.? It is wise to resist this temptation -- and maybe even over-rotate in the other direction -- to allow for some time for the spirit of what you've built to make itself clear; even creators are not always immediately clear on the nuances of their creation.? So we tried hard to resist the calls for unnecessary methods, knowing that they could always be added, but not taken away, and also, allowing for the true gaps to emerge from usage.? (The first method to be added, takeWhile(), was the very opposite of a convenience; it represented a reasonable use case that the original design didn't support.) So, why toList now?? Well, a number of reasons.? Collecting to a list is one of the most common terminal operations, so any small irritant (like a clumsy locution) adds up.? And, as has been pointed out, it can be more efficient if it is brought into the stream core rather than held at arm's length through Collector.? So if we're going to compromise our principles in one place, after thinking about it for a long time, this seemed a worthy candidate.? (And still, we hesitate, because we knew it would be firing the starting gun for the "But where's toSet?" arguments.) So yes, there are lots of good reasons to continue to Just Say No to conveniences, but, there are also reasonable times to make exceptions -- especially when it is not purely about convenience. And, data suggests that toList is 5-10x more popular than the next most popular collector, so there's a clear argument to say that toList is pretty special, and we can stop there. > List is a mutable interface. This is true to an extent (though even the specification of List makes it clear the mutative methods are strictly optional), but even if it were absolutely true, I am still not sure how relevant it is to what streams should do.? When I wrote Collectors::toList, ArrayList was indeed the obvious default implementation choice -- but it was also obviously not a very good choice.? We didn't have an efficient unmodifiable collection at the time, and wrapping with unmodifiableList seemed like taxing a lot of well-behaved users for the would-be sins of the few.? But if we had efficient unmodifiable collections then, I would absolutely, positively have made that choice. Streams is an API that takes functional principles to heart, sometimes even in ways that are uncomfortable to Java developers. (For example, it imposes constraints on the lambdas we pass to its methods, which are the Java analogues of purity and side-effect freedom -- which are not necessarily familiar constraints.)? Data structures are about managing and organizing data in memory, but streams are about capturing and composing behavior, not data. (Obviously, streams consume and produce data at their extreme points, but it tries to make the fewest possible assumptions about the form that data takes.)? Where Stream meets List, Stream is allowed to have an opinion about what kinds of lists it likes better, and an unmodifiable list seems far more in the spirit of Streams.? And of course, collect(toCollection(f)) lets you collect to whatever sort of collection you like. > A convention was established in 2014 with Collectors.toList() returning a mutable List (ArrayList). I am having a hard time expressing just how much I disagree with the sentiment behind this claim.? I knew, when I was writing Collectors::toList, that I would someday be having this discussion; my best efforts to head this discussion off were memorialized in the specification for Collectors::toList: > There are no guarantees on the type, mutability, serializability, or > thread-safety of the|List|returned; if more control over the > returned|List|is required, use|toCollection(Supplier)| > . I'd hope this would be interpreted as: "Dear developer who assumes that, just because this returns ArrayList today, that somehow it is reasonable to assume toList will always return an ArrayList: you are wrong, and I hope you have the good sense to never make this argument out loud." The reason that this "reasonable-seeming" assumption -- that what the first implementation does is reasonable to take as normative, even when the spec says otherwise -- is so toxic, is that it cripples the ability of the platform to evolve.? There's a reason we write specifications for APIs; because implementations are intrinsically accidental and contextual, and context changes out from under us.? Even when writing it, I was aware of the degree to which programmers would be overwhelmingly tempted (despite what I hoped was their better judgment) to count on the mutability of the returned list if that is what they wanted.? Saying `toCollection(ArrayList::new)`, which guarantees exactly the characteristics such users would want, is Just Not That Hard.? Sure, saying toList() is easier, but the tradeoff there is you accept whatever (compliant) List the library wants to serve up, and the library gets some say in what that is, and which might even vary from tuesday to wednesday.?? A toList() method should try to balance the competing concerns for what is the most reasonable default, and when the JDK improves in a way that shifts that balance, or the context shifts, the JDK should be able to improve with it. So, this "establish a convention" claim is dangerous because it pushes us towards the assumption that everything the JDK does, even the things it *clearly specifies as implementation details that might change*, can never change.? Which means we would have to be *even more deliberate* about anything we do, which means the rate at which we can move forward is *even slower*. But, you are making an even stronger claim than that! ? We're not trying to change the implementation of Collectors::toList (which the spec makes clear should might happen.)? We're adding _another_ method with that name, somewhere else.? Which makes the above argument even more dangerous -- essentially, it says "don't use a word in any API ever, unless you are prepared to interpret it exactly the same way in all future contexts."? Surely, you see how this doesn't lead to a world we want to live in. So, what should `Stream::toList` mean?? it should mean: return whatever kind of list that Streams thinks is the best all-around default implementation to use, based on the best understanding of what typical users want.? This involves balancing a lot of things, and that balance can move over time. We could call this toUnmodifiableList, and there's surely a certain logic to that.? But, this is likely to have unintended consequences.? First, the fact that the name is fussier makes it even less attractive as a convenience, which is an argument to not do it at all.? Users who mostly count characters (which is sadly common) would be more likely to continue to use collect(toList()), even if the new method is better in multiple ways.? If we have Stream::toUnmodifiableList, it is *even more likely* to generate demands for other toXxxList conveniences.? Worse, it would likely generate arguments for a toList that works the same as collect(toList()) -- which takes an existing "accidental mutability" problem and guarantees that problem into the infinite future.? It's bad enough that collect(toList()) yields a mutable list -- it would be even worse for Stream::toList to do the same.? Most users don't need mutability, and are better off not getting it if they don't need it; they should ask for it if they need it. > [1] Example usages of Eclipse Collections toList: > > > // toList result is mutable for all of these usages with Eclipse Collections > List list1 = mutableSet.toList(); > List list2 = mutableSet.asLazy().toList(); > List list3 = mutableSet.asParallel(Executors.newWorkStealingPool(), 10).toList(); > List list4 = mutableSet.stream().collect(Collectors.toList()); > List list5 = mutableSet.stream().collect(Collectors2.toList()); These are nice, but there's a subtle difference here that is salient.? Eclipse Collections attempts to integrate data management and behavioral composition into a single library.? This is a fine goal, but it does mean that the behavioral methods have more responsibility to fit with the data-management side of the story. Streams took an almost opposite interpretation -- one reason NOT to do a Stream::toList method was that it overly coupled Streams to Collections.? Laundering stream-to-List via a specific collector (which is clearly more of a "plug in" than core functionality) seemed preferable.? We chose more of an arms-length relationship between Stream and Collections.? Again, different philosophies. (Adding Stream::toList goes back on that a bit, after thinking about it for a bunch of years, and deciding it was OK in this case.) The primary cost here is a seeming "inconsistency", because people have been able to convince themselves that `toList()` means "to ArrayList", and now, there will be cases where that is not true. Given the choice between catering to explicitly wrong assumptions (the spec even says "don't make this assumption"!), and improving the platform over time, I choose the latter.? Consistency is a good baseline goal, but consistencies can be taken to foolish extremes. From mbaesken at openjdk.java.net Fri Feb 5 15:28:46 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 5 Feb 2021 15:28:46 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile Message-ID: Hello, Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. See also the Sonar check result : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG public static boolean isClassPathAttributePresent(String path) { try { Manifest man = (new JarFile(path)).getManifest(); Use try-with-resources or close this "JarFile" in a "finally" clause. ------------- Commit messages: - JDK-8261237 Changes: https://git.openjdk.java.net/jdk/pull/2429/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2429&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261237 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2429.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2429/head:pull/2429 PR: https://git.openjdk.java.net/jdk/pull/2429 From gziemski at openjdk.java.net Fri Feb 5 15:47:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Feb 2021 15:47:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <1WBui88c5lauE5a6N6u6iqV93EDULATd6jx-VTi7ctY=.4fc4b9e2-1e6d-4ff4-9693-27cdbb06e7ef@github.com> On Fri, 5 Feb 2021 12:26:27 GMT, Anton Kozlov wrote: >> Marked as reviewed by ihse (Reviewer). > >> I haven't got a MacOS AArch64 system right now. Is it possible to >> enable W^X in Linux in order to kick the tyres? > > I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state. > _Mailing list message from [daniel.daugherty at oracle.com](mailto:daniel.daugherty at oracle.com) on [security-dev](mailto:security-dev at openjdk.java.net):_ > > On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote: > > @magicus - I'm good with both of these answers. I personally like 'macosx'. > > Dan It's no longer `macosx`, it's just `macos` now - see https://en.wikipedia.org/wiki/MacOS ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From coleenp at openjdk.java.net Fri Feb 5 16:06:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Feb 2021 16:06:46 GMT Subject: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 03:00:05 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments and copyright. > > src/hotspot/share/classfile/javaClasses.cpp line 4415: > >> 4413: >> 4414: // This field means that a security manager can be installed so we still have to >> 4415: // populate the ProtectionDomainCacheTable. > > No this field returns the installed SM if any. It doesn't tell you anything about whether you can install a SM or not (though obviously if non-NULL then you could). // This field tells us that a security manager is installed. How about I just put this. I had a bug earlier that this explained to me but the allow_security_manager() also explains it. > src/java.base/share/classes/java/lang/System.java line 163: > >> 161: >> 162: // indicates if a security manager is possible >> 163: // @implNote The HotSpot JVM hardcodes the value of NEVER. > > You don't need this if the VM reads the value of NEVER. ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/2410 From akozlov at openjdk.java.net Fri Feb 5 16:07:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 16:07:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update signal handler part for debugger ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/8652d21d..0d0e9baf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=10-11 Stats: 16 lines in 1 file changed: 5 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 5 16:17:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 16:17:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski wrote: >> using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks >> >> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64: >> https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524 >> and aarch64: >> https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323 >> (What happened with the formatting here, ugh?) >> >> Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that? > > So it should be: > > #if defined(__APPLE__) > // lldb (gdb) installs both standard BSD signal handlers, and mach exception > // handlers. By replacing the existing task exception handler, we disable lldb's mach > // exception handling, while leaving the standard BSD signal handlers functional. > // > // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking > // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking > // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization > kern_return_t kr; > kr = task_set_exception_ports(mach_task_self(), > EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC > AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION), > MACH_PORT_NULL, > EXCEPTION_STATE_IDENTITY, > MACHINE_THREAD_STATE); > > assert(kr == KERN_SUCCESS, "could not set mach task signal handler"); > #endif Thanks! I've updated the PR with this code, with extra indentation of `AARCH64_ONLY(...)` line, since this is continuation of the first parameter. I'll fix the formatting in os_bsd_arch64.cpp along other changes to `bsd_aarch64` directory ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From raffaello.giulietti at gmail.com Fri Feb 5 16:20:53 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 5 Feb 2021 17:20:53 +0100 Subject: Fast and cheap (Double|Float)::toString Java algorithm Message-ID: Hello, as a reminder, a Java implementation of Schubfach [1] intended to replace the current slow and expensive OpenJDK (Double|Float)::toString algorithm has been discussed, presented and contributed to this mailing list in several posts. The last implementation is available in pre-Skara webrev form, as referenced in [2]. On my laptop hardware, the speedup factor is 17.7x wrt OpenJDK. Recently, Alexander Bolz translated Schubfach to C++ for the purpose of comparing the performance of several bin2dec floating-point numbers algorithms [3]. In the meantime, Junekey Jeon implemented and perfected his own Dragonbox in C++, a new algorithm based on Schubfach [4]. From [5]: "In addition to the core idea of Schubfach, Dragonbox utilizes some Grisu-like ideas to minimize the number of expensive 128-bit ? 64-bit multiplications, at the cost of having more branches and divisions-by-constants." In the C++ ecosystem, Schubfach has been the fastest known algorithm before being gently pushed aside by Dragonbox, as can be seen in the graphs in [3]. While developing Schubfach back in 2018, I experimented myself with blending core Schubfach with my own earlier algorithm similar to Grisu. However, probably due to uncontrollable JIT compilation behavior, I could not observe any benefit. On the contrary, I measured performance drops probably because of the added complexity, which is public enemy nr. 1 for JIT compilers. Therefore, I opted for the simpler current design that seemed more suitable for (the then 2018 version of) C2. I hope this can somehow revive this community's interest and confidence toward Schubfach to definitely supplant the current expensive (Double|Float)::toString algorithm. Greetings Raffaello ---- [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html [3] https://github.com/abolz/Drachennest [4] https://github.com/jk-jeon/dragonbox [5] https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf From akozlov at openjdk.java.net Fri Feb 5 17:23:50 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 5 Feb 2021 17:23:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: > >> 91: CPU_MARVELL = 'V', >> 92: CPU_INTEL = 'i', >> 93: CPU_APPLE = 'a', > > The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined? They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From smarks at openjdk.java.net Fri Feb 5 17:28:42 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 5 Feb 2021 17:28:42 GMT Subject: RFR: 8261096: Convert jlink tool to use Stream.toList() In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 22:45:10 GMT, Ian Graves wrote: > A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559). This is an enhancement to update jlink's usage of `Collections.toList()` to `Stream.toList()`. Aside from the simplification issues, the Collectors.toList() => Stream.toList() conversions look fine. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 569: > 567: ? Stream.of(Arrays.copyOfRange(args, i, args.length)) > 568: .toList() > 569: : Collections.emptyList(); This is probably out of scope for a simple toList() conversion, but there are some additional ways this code could be simplified. It's possible to stream a subrange of an array directly: `Arrays.stream(args, i, args.length).toList()` Since a zero-length array subrange results in a valid zero-length list, the enclosing ternary is unnecessary: `return Arrays.stream(args, ++i, args.length).toList();` It's also possible to do this without using streams at all, `return List.copyOf(Arrays.asList(args).subList(++i, args.length));` but this actually seems more cumbersome than streaming the array subrange. In any case, perhaps this sort of cleanup could be reserved for a future changeset from the jlink maintainer. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 579: > 577: return Stream.of(Arrays.copyOfRange(args, i, args.length)) > 578: .toList(); > 579: } As above, stream an array subrange. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2416 From asemenyuk at openjdk.java.net Fri Feb 5 17:44:21 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 5 Feb 2021 17:44:21 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v6] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: 8254702: jpackage app launcher crashes on CentOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2320/files - new: https://git.openjdk.java.net/jdk/pull/2320/files/b2413570..3e73e074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2320&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2320/head:pull/2320 PR: https://git.openjdk.java.net/jdk/pull/2320 From asemenyuk at openjdk.java.net Fri Feb 5 17:47:42 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 5 Feb 2021 17:47:42 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v2] In-Reply-To: References: <4vgEo6OKMRjvH6Uo_PsYddUZ-XTyIe8PKKuUGxoXP3A=.4723b577-89b3-4c0e-bf96-1f17a47313a8@github.com> Message-ID: On Mon, 1 Feb 2021 18:35:54 GMT, Alexey Semenyuk wrote: >>> "common" was perfectly enough until this change. Unfortunately we cant just drop new C sources in "common" dir because we don't want them to be compiled with g++. That is why need new common directory (applauncherlibcommon) for C sources. >> >> We pick compiler based on file suffix, not directory, so it shouldn't matter where you put a .c file, it should always be compiled with gcc and .cpp files with g++. Which compiler is used to launch the linker can however differ. That's configured for each SetupNativeCompilation call with the different TOOLCHAIN settings. > > Erik, thank you for explanation. > > The launcher on Linux should not be linked with c++ runtime, that is why TOOLCHAIN_DEFAULT is used as a value for TOOLCHAIN property in BUILD_JPACKAGE_APPLAUNCHEREXE target on Linux. > > Will SetupNativeCompilation work if `TOOLCHAIN=TOOLCHAIN_DEFAULT` and there are .cpp sources are in directories passed in `SRC` property of SetupNativeCompilation? Will it try to compile these sources? If it will ignore them and pick only .c files, that would be perfect. Reworked the fix to avoid creation of extra source directories and file renames. ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From erikj at openjdk.java.net Fri Feb 5 17:55:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 5 Feb 2021 17:55:44 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v6] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 17:44:21 GMT, Alexey Semenyuk wrote: >> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 >> >> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. >> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > 8254702: jpackage app launcher crashes on CentOS I like this much better, thanks for taking the time! Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2320 From igraves at openjdk.java.net Fri Feb 5 18:00:41 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 5 Feb 2021 18:00:41 GMT Subject: RFR: 8261096: Convert jlink tool to use Stream.toList() In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 17:11:24 GMT, Stuart Marks wrote: >> A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559). This is an enhancement to update jlink's usage of `Collections.toList()` to `Stream.toList()`. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 569: > >> 567: ? Stream.of(Arrays.copyOfRange(args, i, args.length)) >> 568: .toList() >> 569: : Collections.emptyList(); > > This is probably out of scope for a simple toList() conversion, but there are some additional ways this code could be simplified. It's possible to stream a subrange of an array directly: > > `Arrays.stream(args, i, args.length).toList()` > > Since a zero-length array subrange results in a valid zero-length list, the enclosing ternary is unnecessary: > > `return Arrays.stream(args, ++i, args.length).toList();` > > It's also possible to do this without using streams at all, > > `return List.copyOf(Arrays.asList(args).subList(++i, args.length));` > > but this actually seems more cumbersome than streaming the array subrange. In any case, perhaps this sort of cleanup could be reserved for a future changeset from the jlink maintainer. Agree that it's less cumbersome, but will keep it for a future clean up. ------------- PR: https://git.openjdk.java.net/jdk/pull/2416 From herrick at openjdk.java.net Fri Feb 5 18:01:45 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 5 Feb 2021 18:01:45 GMT Subject: RFR: 8254702: jpackage app launcher crashes on CentOS [v6] In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 17:44:21 GMT, Alexey Semenyuk wrote: >> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 >> >> The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. >> At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). >> App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. >> >> Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. >> >> Layout of jpackage's native code changed: >> - `common`: code shared between all jpackage binaries. >> - `applauncher`: launcher only code. >> - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. >> - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > 8254702: jpackage app launcher crashes on CentOS looks ok if build team approves ------------- Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2320 From naoto at openjdk.java.net Fri Feb 5 18:19:39 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 5 Feb 2021 18:19:39 GMT Subject: Integrated: 8261179: Norwegian =?UTF-8?B?Qm9rbcOlbA==?= Locale fallback issue In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 22:17:12 GMT, Naoto Sato wrote: > Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order. > > [1] https://unicode-org.atlassian.net/browse/CLDR-2698 This pull request has now been integrated. Changeset: 4a1814cb Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/4a1814cb Stats: 43 lines in 2 files changed: 22 ins; 1 del; 20 mod 8261179: Norwegian Bokm?l Locale fallback issue Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/2414 From asemenyuk at openjdk.java.net Fri Feb 5 20:47:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 5 Feb 2021 20:47:41 GMT Subject: Integrated: 8254702: jpackage app launcher crashes on CentOS In-Reply-To: References: Message-ID: <63LdvHtUr3enohVek7LRYoDlk1q6i8S-Z2Ef1Er5TTA=.3bb1fa15-e41c-4814-a71f-888df4925f36@github.com> On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote: > Fix for https://bugs.openjdk.java.net/browse/JDK-8254702 > > The fix splits Linux app launcher in app launcher and launcher shared lib. App launcher is pure C and doesn't have C++ code. App launcher lib incorporates bulk of C++ code from app launcher. > At startup app launcher loads launcher shared lib and calls functions it provides to get data for launching JVM (path to jli lib and arguments for JLI_Launch function call). > App launcher unloads launcher shared lib before launching JVM to remove C++ runtime from the process memory. > > Getting rid of C++ code from app launcher required to rewrite app installation location lookup code from C++ to C. LinuxPackage.c source is C alternative for https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Package.cpp and https://github.com/openjdk/jdk/blob/master/src/jdk.jpackage/linux/native/applauncher/Executor.cpp. > > Layout of jpackage's native code changed: > - `common`: code shared between all jpackage binaries. > - `applauncher`: launcher only code. > - `applauncherlib`: launcher lib code on Linux and launcher code on other platforms. > - `applaunchercommon`: code shared between launcher and launcher lib on Linux and launcher code on other platforms. This pull request has now been integrated. Changeset: fac3c2d2 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/fac3c2d2 Stats: 1315 lines in 17 files changed: 1111 ins; 150 del; 54 mod 8254702: jpackage app launcher crashes on CentOS Reviewed-by: almatvee, erikj, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/2320 From amenkov at openjdk.java.net Fri Feb 5 21:14:53 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 5 Feb 2021 21:14:53 GMT Subject: RFR: 8248162: serviceability/attach/RemovingUnixDomainSocketTest.java failed Message-ID: JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools). The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings ------------- Commit messages: - JDK-8248162 Changes: https://git.openjdk.java.net/jdk/pull/2438/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248162 Stats: 11 lines in 7 files changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2438/head:pull/2438 PR: https://git.openjdk.java.net/jdk/pull/2438 From bpb at openjdk.java.net Fri Feb 5 21:15:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 5 Feb 2021 21:15:44 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math [v2] In-Reply-To: <_94F8Y_6vzkytWWm0s6CgyCfDI8DbpcqL2fScgjp6J8=.5e9e1a8e-7855-49a9-a715-5689306683ee@github.com> References: <_94F8Y_6vzkytWWm0s6CgyCfDI8DbpcqL2fScgjp6J8=.5e9e1a8e-7855-49a9-a715-5689306683ee@github.com> Message-ID: On Thu, 4 Feb 2021 18:30:57 GMT, Joe Darcy wrote: >> Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. >> >> Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. >> >> If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. >> >> There is no intention at the moment to change the behavior of pow to align with IEEE 754. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Correct acos spec and fix regression test. src/java.base/share/classes/java/lang/Math.java line 237: > 235: *
    • If the argument is NaN or its absolute value is greater > 236: * than 1, then the result is NaN. > 237: *
    • If the argument is {@code 1.0}, the result is {@code +0.0}. `+0.0` is used here but in several cases below it is written out as `positive zero`. src/java.base/share/classes/java/lang/Math.java line 716: > 714: * the infinite power as a large integer (large-magnitude > 715: * floating-point numbers are numerically integers, specifically > 716: * even integer) and therefore specifies {@code 1.0} be returned. In this sentence `integer` should be plural. ------------- PR: https://git.openjdk.java.net/jdk/pull/2395 From dcubed at openjdk.java.net Fri Feb 5 21:24:44 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Feb 2021 21:24:44 GMT Subject: RFR: 8248162: serviceability/attach/RemovingUnixDomainSocketTest.java failed In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov wrote: > JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools). > The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings What kind of testing was done in Mach5? ------------- PR: https://git.openjdk.java.net/jdk/pull/2438 From winterhalter at openjdk.java.net Fri Feb 5 21:29:59 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Fri, 5 Feb 2021 21:29:59 GMT Subject: RFR: 8228988: AnnotationParser throws NullPointerException on incompatible member type Message-ID: When a class is compiled against a version of an annotation that is later loaded in an incompatible manner where an enum-typed member is changed into an annotation or vice versa, the reflection API currently throws a `NullPointerException` upon accessing the member. Instead an `AnnotationTypeMismatchException` should be thrown. This change adjusts the parsing to trigger the correct exception. ------------- Commit messages: - 8228988: AnnotationParser throws NullPointerException on incompatible member type Changes: https://git.openjdk.java.net/jdk/pull/2439/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8228988 Stats: 182 lines in 3 files changed: 178 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2439.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2439/head:pull/2439 PR: https://git.openjdk.java.net/jdk/pull/2439 From michaelm at openjdk.java.net Fri Feb 5 22:28:10 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 5 Feb 2021 22:28:10 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon 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 ten additional commits since the last revision: - Merge branch 'master' into 8252971-socket-attributes - update - update - update - update - update after Alan's first review - Merge branch 'master' into 8252971-socket-attributes - test update - initial fix for review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/fb6c719d..b61686f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=00-01 Stats: 10870 lines in 557 files changed: 6876 ins; 2384 del; 1610 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From isipka at openjdk.java.net Sat Feb 6 00:08:43 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Sat, 6 Feb 2021 00:08:43 GMT Subject: Integrated: 8259268: Refactor InheritIO shell test as java test In-Reply-To: References: Message-ID: <7aJKw9DG-Xr_N8oQstzs7FZFg-3TbMmzRjbckA1q7Xc=.58b7d501-8c0f-4589-9ee2-fcec2c8640d3@github.com> On Fri, 27 Nov 2020 18:50:19 GMT, Ivan ?ipka wrote: > @iignatev could you please review? Thank you. > > note to self: > jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java This pull request has now been integrated. Changeset: fb46d4e5 Author: Ivan ?ipka Committer: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/fb46d4e5 Stats: 215 lines in 3 files changed: 84 ins; 131 del; 0 mod 8259268: Refactor InheritIO shell test as java test Reviewed-by: iignatyev, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/1484 From joehw at openjdk.java.net Sat Feb 6 00:45:54 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 6 Feb 2021 00:45:54 GMT Subject: RFR: 8261209: isStandalone property: remove dependency on pretty-print Message-ID: A quick fix to remove isStandalone's dependency on pretty-print. ------------- Commit messages: - 8261209: isStandalone property: remove dependency on pretty-print Changes: https://git.openjdk.java.net/jdk/pull/2442/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2442&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261209 Stats: 36 lines in 3 files changed: 18 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2442.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2442/head:pull/2442 PR: https://git.openjdk.java.net/jdk/pull/2442 From sirinath1978m at gmail.com Sat Feb 6 04:20:38 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Sat, 6 Feb 2021 09:50:38 +0530 Subject: Fast and cheap (Double|Float)::toString Java algorithm In-Reply-To: References: Message-ID: Hello, I am working on a port of DragonBox to Java. If there is interest in contributing this is most welcome. Suminda On Fri, 5 Feb 2021 at 21:51, Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > Hello, > > as a reminder, a Java implementation of Schubfach [1] intended to > replace the current slow and expensive OpenJDK (Double|Float)::toString > algorithm has been discussed, presented and contributed to this mailing > list in several posts. The last implementation is available in pre-Skara > webrev form, as referenced in [2]. On my laptop hardware, the speedup > factor is 17.7x wrt OpenJDK. > > > > Recently, Alexander Bolz translated Schubfach to C++ for the purpose of > comparing the performance of several bin2dec floating-point numbers > algorithms [3]. > > In the meantime, Junekey Jeon implemented and perfected his own > Dragonbox in C++, a new algorithm based on Schubfach [4]. From [5]: "In > addition to the core idea of Schubfach, Dragonbox utilizes some > Grisu-like ideas to minimize the number of expensive 128-bit ? 64-bit > multiplications, at the cost of having more branches and > divisions-by-constants." > > In the C++ ecosystem, Schubfach has been the fastest known algorithm > before being gently pushed aside by Dragonbox, as can be seen in the > graphs in [3]. > > > > While developing Schubfach back in 2018, I experimented myself with > blending core Schubfach with my own earlier algorithm similar to Grisu. > However, probably due to uncontrollable JIT compilation behavior, I > could not observe any benefit. On the contrary, I measured performance > drops probably because of the added complexity, which is public enemy > nr. 1 for JIT compilers. Therefore, I opted for the simpler current > design that seemed more suitable for (the then 2018 version of) C2. > > > > I hope this can somehow revive this community's interest and confidence > toward Schubfach to definitely supplant the current expensive > (Double|Float)::toString algorithm. > > > Greetings > Raffaello > > ---- > > [1] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN > [2] > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065297.html > [3] https://github.com/abolz/Drachennest > [4] https://github.com/jk-jeon/dragonbox > [5] > https://github.com/jk-jeon/dragonbox/blob/master/other_files/Dragonbox.pdf > From alanb at openjdk.java.net Sat Feb 6 17:15:52 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 6 Feb 2021 17:15:52 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: References: Message-ID: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> On Fri, 5 Feb 2021 22:28:10 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > Michael McMahon 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 ten additional commits since the last revision: > > - Merge branch 'master' into 8252971-socket-attributes > - update > - update > - update > - update > - update after Alan's first review > - Merge branch 'master' into 8252971-socket-attributes > - test update > - initial fix for review The changes are a bit disruptive but I agree are necessary to improve the experience when socket files are encountered on the file system. I have focused on the changes to the implementation, I see Daniel is focused on the test so I only lightly skimmed that. src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344: > 342: Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT), > 343: 0L); > 344: fc.close(); checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on. Minor nit is the params to newFileChannel is are mis-aligned now. src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 866: > 864: > 865: try { > 866: // needs one additional flag to open a Unix domain socket The comment here is confusing as there are two flags. src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 859: > 857: > 858: /** > 859: * returns INVALID_HANDLE_VALUE if path is not a socket Can you change this to "Returns". ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Sat Feb 6 20:38:45 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sat, 6 Feb 2021 20:38:45 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> References: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> Message-ID: On Sat, 6 Feb 2021 17:09:11 GMT, Alan Bateman wrote: >> Michael McMahon 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 ten additional commits since the last revision: >> >> - Merge branch 'master' into 8252971-socket-attributes >> - update >> - update >> - update >> - update >> - update after Alan's first review >> - Merge branch 'master' into 8252971-socket-attributes >> - test update >> - initial fix for review > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344: > >> 342: Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT), >> 343: 0L); >> 344: fc.close(); > > checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on. > > Minor nit is the params to newFileChannel is are mis-aligned now. So, if the reparse point is a symbolic link, and if the target of the link does not exist, then ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible. >From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time. I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Sat Feb 6 20:44:41 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sat, 6 Feb 2021 20:44:41 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: References: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> Message-ID: On Sat, 6 Feb 2021 20:35:58 GMT, Michael McMahon wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344: >> >>> 342: Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT), >>> 343: 0L); >>> 344: fc.close(); >> >> checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on. >> >> Minor nit is the params to newFileChannel is are mis-aligned now. > > So, if the reparse point is a symbolic link, and if the target of the link does not exist, then ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible. > > From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time. > > I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned. Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From lancea at openjdk.java.net Sat Feb 6 20:51:40 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 6 Feb 2021 20:51:40 GMT Subject: RFR: 8261209: isStandalone property: remove dependency on pretty-print In-Reply-To: References: Message-ID: On Sat, 6 Feb 2021 00:38:15 GMT, Joe Wang wrote: > A quick fix to remove isStandalone's dependency on pretty-print. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2442 From darcy at openjdk.java.net Sun Feb 7 00:45:03 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 7 Feb 2021 00:45:03 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math [v3] In-Reply-To: References: Message-ID: <-NcTC711LHxE8gEz1rnN6cHko6tW-BBcRJPUJ5eCfdg=.d4d31092-15cf-45ee-9a71-a42b95e7a08c@github.com> > Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. > > Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. > > If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. > > There is no intention at the moment to change the behavior of pow to align with IEEE 754. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2395/files - new: https://git.openjdk.java.net/jdk/pull/2395/files/efd606ff..0c6134d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2395&range=01-02 Stats: 53 lines in 3 files changed: 36 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/2395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2395/head:pull/2395 PR: https://git.openjdk.java.net/jdk/pull/2395 From naoto at openjdk.java.net Sun Feb 7 02:04:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 7 Feb 2021 02:04:44 GMT Subject: RFR: 8261209: isStandalone property: remove dependency on pretty-print In-Reply-To: References: Message-ID: On Sat, 6 Feb 2021 00:38:15 GMT, Joe Wang wrote: > A quick fix to remove isStandalone's dependency on pretty-print. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2442 From weijun.wang at oracle.com Sun Feb 7 03:42:23 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Sun, 7 Feb 2021 03:42:23 +0000 Subject: Module jdk.jartool should provide jarsigner tool In-Reply-To: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> References: <00c18610-5351-6b34-9583-fd555a275d25@oracle.com> Message-ID: <7DBC87D5-495C-44AE-AD41-0FF4CAD140CA@oracle.com> We considered this before but thought jarsigner has too many options, and the password prompt thing is certainly a pain. Also the verification part are all based on public APIs and only the signing part is worth investigating. Finally we produce the JarSigner API in the jdk.security.jarsigner package in the jdk.jartool module, and move most signing code in jarsigner there. It?s certainly much more programmer-friendly than the jarsigner tool. ?Max > On Feb 4, 2021, at 5:36 AM, Alan Bateman wrote: > > On 04/02/2021 07:38, Christian Stein wrote: >> Module jdk.jartoo already provides java.util.spi.ToolProvider with >> sun.tools.jar.JarToolProvider. [0] >> >> Is there a reason why it does provide a JarSignerToolProvider allowing >> `jarsigner` to be run in-process? Perhaps too many System.exit() calls >> in sun/security/tools/jarsigner/Main.java? >> >> > cc'ing security-dev as that is where the jarsigner tool is maintained. > > This may have come up in JDK 9 but I can't find any mails in the archives. Yes, it would need a bit of refactoring so that the System.exit is only called when invoked via the launcher/main method. There are also CLI options that prompt for a password that may not be suitable for programmatic use. I'm sure Max or others on security-dev will have more to say on this. > > -Alan From alanb at openjdk.java.net Sun Feb 7 09:18:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 7 Feb 2021 09:18:46 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: References: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> Message-ID: On Sat, 6 Feb 2021 20:41:38 GMT, Michael McMahon wrote: >> So, if the reparse point is a symbolic link, and if the target of the link does not exist, then ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible. >> >> From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time. >> >> I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned. > > Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket. Moving it to a separate method would make it easier to maintain and discuss here but I would really prefer if it checked the reparse tag and re-throw the original exception if the tag is IO_REPARSE_TAG_SYMLINK. That way it wouldn't get tripped up by ERROR_CANT_ACCESS_FILE being thrown for other reasons, e.g. sym link -> sym link -> target where an intermediate sym link can't be accessed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From attila at openjdk.java.net Sun Feb 7 13:35:42 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 7 Feb 2021 13:35:42 GMT Subject: RFR: 8198540: Dynalink leaks memory when generating type converters [v7] In-Reply-To: References: <3p6wFSLodVRRy2-ZBAAWtpoFjEaGkNBPNVFAtXwfj8U=.24d43d1b-03d6-42a6-a036-b1c55fe156ac@github.com> <3aOD4KfYXvu_fe2JRGevhkCsChzQN1FfT6rwZl5Qytk=.82cfe6f8-3026-419b-9961-6cc63b16d8d8@github.com> <7EjvqRxHVP05KEfozC-pv8WaQ-hSMKWMaE3 oXwcymjE=.19daa9d3-5dae-409f-8d2b-62d76c485b31@github.com> <6SyoHul5LMKYpyvpUjmC0fvU4XnURtM9zs2FOxMfKbE=.5ff01a63-89b4-4057-a446-25e3cc7fc50a@github.com> Message-ID: On Sun, 10 Jan 2021 23:30:58 GMT, Peter Levart wrote: >>> How frequent are situations where the two classloaders are unrelated? >> >> I think they'd be extremely unlikely. The only user of these right now is Dynalink's type converter factory. I _can imagine_ a situation where there's a conversion from a dynamic language runtime's internal "object" type to an application-specific Java interface, or from its internal "function object" type to an app-specific Java SAM type, and for some reason the app-specific types aren't in the same or descendant class loader of the language runtime's loader. >> Frankly, I'd expect 99.99% of the time, app classes would be in the same-or-descendant class loader relative to the dynamic language runtime types. It'd have to be a really exotic setup for this not to be the case, but I'd rather not second guess the users and provide a reasonable functionality even in this case. >> If you're thinking of rather throwing an exception when they're unrelated? well, we could certainly do that but I give it a mean time of six months before somebody runs into it and asks about it on Stack Overflow. > > Well, I was just thinking if it might be more frequent and would benefit from caching the result too. But if it is not, then what you have now is OK. @plevart would you be then be okay with approving this PR? Also, @hns or @sundararajana can I maybe get a review from either of you? ------------- PR: https://git.openjdk.java.net/jdk/pull/1918 From plevart at openjdk.java.net Sun Feb 7 15:47:42 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Sun, 7 Feb 2021 15:47:42 GMT Subject: RFR: 8198540: Dynalink leaks memory when generating type converters [v7] In-Reply-To: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> References: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> Message-ID: On Sun, 10 Jan 2021 17:04:19 GMT, Attila Szegedi wrote: >> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_ >> >> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons. >> >> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?) >> >> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution. >> >> And it exists! I ended up replacing the `ClassValue>` construct with a ground-up implementation of `BiClassValue`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction, Class, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders. >> >> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way. >> >> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them. > > Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: > > Rename ClassLoaderRelation to RetentionDirection; it is better self-documenting this way. I think this looks good Attila. ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1918 From michaelm at openjdk.java.net Sun Feb 7 19:08:02 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sun, 7 Feb 2021 19:08:02 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: References: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> Message-ID: On Sun, 7 Feb 2021 09:15:35 GMT, Alan Bateman wrote: >> Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket. > > Moving it to a separate method would make it easier to maintain and discuss here but I would really prefer if it checked the reparse tag and re-throw the original exception if the tag is IO_REPARSE_TAG_SYMLINK. That way it wouldn't get tripped up by ERROR_CANT_ACCESS_FILE being thrown for other reasons, e.g. sym link -> sym link -> target where an intermediate sym link can't be accessed. Okay, I can add a check for WindowsFileAttributes.isUnixDomainSocket() in there when ERROR_CANT_ACCESS_FILE is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Sun Feb 7 19:08:02 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sun, 7 Feb 2021 19:08:02 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v3] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: add specific check for unix domain socket ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/b61686f4..de2a3428 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=01-02 Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Sun Feb 7 19:08:06 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sun, 7 Feb 2021 19:08:06 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v2] In-Reply-To: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> References: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com> Message-ID: On Sat, 6 Feb 2021 17:10:39 GMT, Alan Bateman wrote: >> Michael McMahon 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 ten additional commits since the last revision: >> >> - Merge branch 'master' into 8252971-socket-attributes >> - update >> - update >> - update >> - update >> - update after Alan's first review >> - Merge branch 'master' into 8252971-socket-attributes >> - test update >> - initial fix for review > > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 866: > >> 864: >> 865: try { >> 866: // needs one additional flag to open a Unix domain socket > > The comment here is confusing as there are two flags. Okay > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 859: > >> 857: >> 858: /** >> 859: * returns INVALID_HANDLE_VALUE if path is not a socket > > Can you change this to "Returns". Okay ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From redestad at openjdk.java.net Sun Feb 7 19:36:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 7 Feb 2021 19:36:53 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily Message-ID: This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. Testing: tier1-3 ------------- Commit messages: - Merge branch 'master' into lazy_charsets - More finals, copyrights - Improve finality - Initialize charset mapping data lazily Changes: https://git.openjdk.java.net/jdk/pull/2449/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2449&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261254 Stats: 274 lines in 21 files changed: 24 ins; 59 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/2449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2449/head:pull/2449 PR: https://git.openjdk.java.net/jdk/pull/2449 From redestad at openjdk.java.net Sun Feb 7 19:36:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 7 Feb 2021 19:36:53 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 Applications calling `Charset.availableCharsets()` might see a decent startup improvement (125-190ms -> 57-95ms first call overhead). All `DoubleByte`-derived charsets can see a throughput improvement on benchmarks thanks to removing DCL initialization checks with a Holder pattern implementation, which allows static data to be declared final and be more amenable to optimizations: Before: Benchmark (charsetName) Mode Cnt Score Error Units StringDecode.WithCharset.decodeCharset MS932 avgt 15 280.072 ? 17.217 ns/op StringDecode.WithCharset.decodeCharsetName MS932 avgt 15 289.368 ? 18.174 ns/op After: Benchmark (charsetName) Mode Cnt Score Error Units StringDecode.WithCharset.decodeCharset MS932 avgt 15 254.906 ? 15.095 ns/op StringDecode.WithCharset.decodeCharsetName MS932 avgt 15 268.241 ? 15.725 ns/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From redestad at openjdk.java.net Sun Feb 7 19:38:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 7 Feb 2021 19:38:40 GMT Subject: RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource [v2] In-Reply-To: References: Message-ID: <-C1sboY2ZRuN-zJn_YHk2PkS6LZ0Uf22ctav0NS5C_A=.dbb12ea9-8368-44cd-88c5-ff5a4805406b@github.com> On Sun, 31 Jan 2021 15:04:33 GMT, Alan Bateman wrote: >> Nice clean up. LGTM > > @JimLaskey Do you have anything that documents the jimage format that could be checked into the repo to help with future changes in this change? Clearly any such document would need a warning in 96pt font that the format is JDK internal, submit to change from build to build, etc. but it could be helpful when working on this code. @sundararajana @AlanBateman - can I solicit a second review on this? Or an OK from Alan to go ahead and push with the one review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2212 From michaelm at openjdk.java.net Sun Feb 7 20:16:08 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Sun, 7 Feb 2021 20:16:08 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v4] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon 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 11 additional commits since the last revision: - Merge branch 'master' into 8252971-socket-attributes - add specific check for unix domain socket - Merge branch 'master' into 8252971-socket-attributes - update - update - update - update - update after Alan's first review - Merge branch 'master' into 8252971-socket-attributes - test update - ... and 1 more: https://git.openjdk.java.net/jdk/compare/fa59fe8c...746b4762 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/de2a3428..746b4762 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=02-03 Stats: 2471 lines in 59 files changed: 1349 ins; 861 del; 261 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From zhangbodut at gmail.com Mon Feb 8 02:14:14 2021 From: zhangbodut at gmail.com (Bo Zhang) Date: Mon, 8 Feb 2021 10:14:14 +0800 Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2] In-Reply-To: References: Message-ID: <8744E746-D32D-4BD6-A64E-934064A926AB@gmail.com> Request for review, thanks! > On 3 Feb 2021, at 09:29, Bo Zhang wrote: > >> Previously, `ImageBufferCache` contains a ThreadLocal field which holds >> strong reference to `ImageBufferCache$BufferReference.class`. When loaded >> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` >> in memory forever and never being GCed. >> >> The fix replace the old `ImageBufferCache$BufferReference` class with >> `WeakReference`, which is verified by provided test. > > Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8260621: Avoid memory leak in ImageBufferCache > > Previously, `ImageBufferCache` contains a ThreadLocal field which holds > strong reference to `ImageBufferCache$BufferReference.class`. When loaded > from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` > in memory forever and never being GCed. > > The fix replace the old `ImageBufferCache$BufferReference` class with > `WeakReference`, which is verified by provided test. > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/2307/files > - new: https://git.openjdk.java.net/jdk/pull/2307/files/8d61d77d..27b55790 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2307&range=00-01 > > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/2307.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2307/head:pull/2307 > > PR: https://git.openjdk.java.net/jdk/pull/2307 From shade at openjdk.java.net Mon Feb 8 08:33:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 08:33:42 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: References: Message-ID: <8PUTrcwIDEFzi6zE6SUki5IL9Ac-pfNJaTrHg7iCRQ8=.c4979ad8-1d7b-4fab-a5a6-893b3897d602@github.com> On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. This looks good to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2429 From alanb at openjdk.java.net Mon Feb 8 08:38:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Feb 2021 08:38:40 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 I wouldn't expect enumerating all charsets with Charset::availableCharsets to be too common but moving the data to holder class looks okay. The missing "final" in a few places was an oversight. The replacement of the foreach and method ref in getServicesCatalog with imperative code is disappointment but okay here. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2449 From shade at openjdk.java.net Mon Feb 8 08:53:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 08:53:55 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo Message-ID: SonarCloud instance reports as new warning after JDK-8254702: This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. char* getJvmLauncherLibPath(void) { ... if (PACKAGE_TYPE_RPM == pkg->type) { pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; Seems like an obvious typo. Additional tests: - [x] Linux x86_64 (Ubuntu) `tools/jpackage` ------------- Commit messages: - Typo fix Changes: https://git.openjdk.java.net/jdk/pull/2452/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2452&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261298 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2452.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2452/head:pull/2452 PR: https://git.openjdk.java.net/jdk/pull/2452 From shade at openjdk.java.net Mon Feb 8 09:11:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 09:11:55 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath Message-ID: SonarCloud instance reports a new warning after JDK-8254702: "Use of memory after it is freed" char* getJvmLauncherLibPath(void) { ... popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, &launcherLibPath); if (popenStatus) { free(launcherLibPath); <---- frees here goto cleanup; } } cleanup: free(modulePath); freePackageDesc(pkg); return launcherLibPath; <--- here } We need to null it out before returning. Additional testing: - [x] Linux x86_64 (Ubuntu) `tools/jpackage` ------------- Commit messages: - Null it out Changes: https://git.openjdk.java.net/jdk/pull/2453/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2453&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261299 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2453.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2453/head:pull/2453 PR: https://git.openjdk.java.net/jdk/pull/2453 From shade at openjdk.java.net Mon Feb 8 09:22:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 09:22:55 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks Message-ID: After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." int initJvmlLauncherData(JvmlLauncherData* ptr) const { // Store path to JLI library just behind JvmlLauncherData header. char* curPtr = reinterpret_cast(ptr + 1); do { const size_t count = sizeof(char) * (jliLibPath.size() + 1 /* trailing zero */); if (ptr) { std::memcpy(curPtr, jliLibPath.c_str(), count); ptr->jliLibPath = curPtr; } curPtr += count; } while (false); // <---- here There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. Additional testing: - [x] Linux x86_64 (Ubuntu) tools/jpackage ------------- Commit messages: - Replace with {} Changes: https://git.openjdk.java.net/jdk/pull/2454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261300 Stats: 22 lines in 1 file changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/2454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2454/head:pull/2454 PR: https://git.openjdk.java.net/jdk/pull/2454 From stuefe at openjdk.java.net Mon Feb 8 10:26:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 8 Feb 2021 10:26:40 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 09:05:23 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports a new warning after JDK-8254702: > "Use of memory after it is freed" > > char* getJvmLauncherLibPath(void) { > ... > popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, > &launcherLibPath); > if (popenStatus) { > free(launcherLibPath); <---- frees here > goto cleanup; > } > } > > cleanup: > free(modulePath); > freePackageDesc(pkg); > > return launcherLibPath; <--- here > } > > We need to null it out before returning. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Fine and trivial. Thanks for fixing. I tried to understand what the fix for JDK-8254702 does but the issue description and the PR are a bit taciturn. This seems to be way more than just a split of C- and C++ sources as the PR suggested. ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From stuefe at openjdk.java.net Mon Feb 8 10:36:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 8 Feb 2021 10:36:40 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: References: Message-ID: <6IJUt64f_27mx-30qC7JMcPh_x3gg07tX5qUsjZMpOg=.720fb519-9a2c-4929-84dc-933e2a022c1a@github.com> On Mon, 8 Feb 2021 09:05:23 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports a new warning after JDK-8254702: > "Use of memory after it is freed" > > char* getJvmLauncherLibPath(void) { > ... > popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, > &launcherLibPath); > if (popenStatus) { > free(launcherLibPath); <---- frees here > goto cleanup; > } > } > > cleanup: > free(modulePath); > freePackageDesc(pkg); > > return launcherLibPath; <--- here > } > > We need to null it out before returning. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From clanger at openjdk.java.net Mon Feb 8 10:51:50 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 8 Feb 2021 10:51:50 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. Looks correct and straightforward. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2429 From redestad at openjdk.java.net Mon Feb 8 11:15:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 11:15:42 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From redestad at openjdk.java.net Mon Feb 8 11:33:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 11:33:46 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 08:36:21 GMT, Alan Bateman wrote: >> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. >> >> Testing: tier1-3 > > I wouldn't expect enumerating all charsets with Charset::availableCharsets to be too common but moving the data to holder class looks okay. The missing "final" in a few places was an oversight. The replacement of the foreach and method ref in getServicesCatalog with imperative code is disappointment but okay here. I spotted usage of this in a real application. While they could work around it and remove the usage to gain an even larger startup win I figured I should do those that can't do so a favor, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From github.com+10835776+stsypanov at openjdk.java.net Mon Feb 8 11:44:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 8 Feb 2021 11:44:47 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com> On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75: > 73: > 74: protected AbstractCharsetProvider(String pkgPrefixName) { > 75: packagePrefix = pkgPrefixName.concat("."); Hm, I wonder why not just `pkgPrefixName + '.'` here and below? ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From jkuhn at openjdk.java.net Mon Feb 8 12:18:43 2021 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Mon, 8 Feb 2021 12:18:43 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 Looks good to me. src/java.base/share/classes/java/lang/ModuleLayer.java line 936: > 934: for (Module m : nameToModule.values()) { > 935: servicesCatalog.register(m); > 936: } Seems to be unrelated, but it's not a bad change. ------------- Marked as reviewed by jkuhn (Author). PR: https://git.openjdk.java.net/jdk/pull/2449 From redestad at openjdk.java.net Mon Feb 8 12:18:45 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 12:18:45 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com> References: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com> Message-ID: <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com> On Mon, 8 Feb 2021 11:42:23 GMT, ?????? ??????? wrote: >> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. >> >> Testing: tier1-3 > > src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75: > >> 73: >> 74: protected AbstractCharsetProvider(String pkgPrefixName) { >> 75: packagePrefix = pkgPrefixName.concat("."); > > Hm, I wonder why not just `pkgPrefixName + '.'` here and below? Is it something about early init of `StringConcatFactory`? Yes, I wanted to measure the overhead of `Charset` class initialization done by `Charset.availableCharsets()` and the `StringConcatFactory` bootstraps was a reasonable chunk of the cost so I moved them out of the picture. I didn't mind what I ended up with, but if you prefer I can move back to `pkgPrefixName + '.'` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From redestad at openjdk.java.net Mon Feb 8 12:21:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 12:21:42 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 19:44:41 GMT, Johannes Kuhn wrote: >> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. >> >> Testing: tier1-3 > > src/java.base/share/classes/java/lang/ModuleLayer.java line 936: > >> 934: for (Module m : nameToModule.values()) { >> 935: servicesCatalog.register(m); >> 936: } > > Seems to be unrelated, but it's not a bad change. As with the `StringConcatFactory` changes @stsypanov commented on, I did this to reduce noise when zooming in on the cost of `Charset` class initialization stemming from `Charset.availableCharsets()`. I ended up preferring the desugared version, so I left it in. ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From github.com+10835776+stsypanov at openjdk.java.net Mon Feb 8 12:50:41 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 8 Feb 2021 12:50:41 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com> References: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com> <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com> Message-ID: On Mon, 8 Feb 2021 12:16:23 GMT, Claes Redestad wrote: >> src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75: >> >>> 73: >>> 74: protected AbstractCharsetProvider(String pkgPrefixName) { >>> 75: packagePrefix = pkgPrefixName.concat("."); >> >> Hm, I wonder why not just `pkgPrefixName + '.'` here and below? Is it something about early init of `StringConcatFactory`? > > Yes, I wanted to measure the overhead of `Charset` class initialization done by `Charset.availableCharsets()` and the `StringConcatFactory` bootstraps was a reasonable chunk of the cost so I moved them out of the picture. I didn't mind what I ended up with, but if you prefer I can move back to `pkgPrefixName + '.'` here. Let's keep it as is, to me it's a readable as concatenation via `+` ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From info at j-kuhn.de Mon Feb 8 13:29:55 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Mon, 8 Feb 2021 14:29:55 +0100 Subject: JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle In-Reply-To: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> References: <759ab7c5-483d-aeef-9411-4cbe7b331284@j-kuhn.de> Message-ID: I now implemented a prototype for JDK-6824466: [1] The goal I set here was to remove the old AccessorGenerator. The good news: - It works - all tier1 tests pass, except one that requires the old implementation. - A lot of code has been removed. And even more could be removed. The bad news: - I hit a performance regression [2]. The JMH tests were written by Peter Levart [3]. As much as I don't like the old AccessorGenerator, I have to say that it is very optimized. If you have any ideas on how the performance could be improved, or how I could find that out where the performance drops, let me know. - Johannes PS.: I played around with adding some @Stable and @ForceInline annotations, and got a big performance improvement for the const cases (~9 ns/op). But that came with other performance regressions for the non-const cases. [1]: https://github.com/openjdk/jdk/pull/2457 [2]: https://gist.github.com/DasBrain/09b37510955b14f0ad82313df8d8de37#gistcomment-3623292 [3]: http://cr.openjdk.java.net/~plevart/jdk-dev/6824466_MHReflectionAccessors/ From alanb at openjdk.java.net Mon Feb 8 13:43:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Feb 2021 13:43:43 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: References: Message-ID: <2fdyXJvAqfSWA6lM0iifm14gc2eVVekRqovVDapJh2g=.d0a51bd0-58b7-402a-9325-beb83e09d4c7@github.com> On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 87: > 85: * path is not a JAR file or some other error occurs. > 86: */ > 87: public static boolean isClassPathAttributePresent(String path) { Is isClassPathAttributePresent used anywhere? I remember we added VMSupport for use by JVMTI and the attach mechanism but I don't see any usages of this method now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From alanb at openjdk.java.net Mon Feb 8 14:06:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Feb 2021 14:06:55 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario src/java.management/share/classes/javax/management/loading/MLet.java line 1147: > 1145: .toFile(); > 1146: file.deleteOnExit(); > 1147: Files.copy(is, file.toPath()); One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code). The code that follows checks if the file exists, this will always be true when Files.copy succeeds. src/java.base/share/classes/sun/net/www/MimeLauncher.java line 2: > 1: /* > 2: * Copyright (c) 1994, 2020, Oracle and/or its affiliates. All rights reserved. Is MimeEntry.launch still used? I'm wondering if the MimeLauncher can be deleted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From clanger at openjdk.java.net Mon Feb 8 14:28:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 8 Feb 2021 14:28:40 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: <2fdyXJvAqfSWA6lM0iifm14gc2eVVekRqovVDapJh2g=.d0a51bd0-58b7-402a-9325-beb83e09d4c7@github.com> References: <2fdyXJvAqfSWA6lM0iifm14gc2eVVekRqovVDapJh2g=.d0a51bd0-58b7-402a-9325-beb83e09d4c7@github.com> Message-ID: On Mon, 8 Feb 2021 13:41:17 GMT, Alan Bateman wrote: >> Hello, >> Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. >> See also the Sonar check result : >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG >> >> public static boolean isClassPathAttributePresent(String path) { >> try { >> Manifest man = (new JarFile(path)).getManifest(); >> Use try-with-resources or close this "JarFile" in a "finally" clause. > > src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 87: > >> 85: * path is not a JAR file or some other error occurs. >> 86: */ >> 87: public static boolean isClassPathAttributePresent(String path) { > > Is isClassPathAttributePresent used anywhere? I remember we added VMSupport for use by JVMTI and the attach mechanism but I don't see any usages of this method now. Seems you're right. My search for "isClassPathAttributePresent" also didn't yield anything. So why not remove it altogether...? ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From herrick at openjdk.java.net Mon Feb 8 14:34:44 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 8 Feb 2021 14:34:44 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 09:17:46 GMT, Aleksey Shipilev wrote: > After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." > > int initJvmlLauncherData(JvmlLauncherData* ptr) const { > // Store path to JLI library just behind JvmlLauncherData header. > char* curPtr = reinterpret_cast(ptr + 1); > do { > const size_t count = sizeof(char) > * (jliLibPath.size() + 1 /* trailing zero */); > if (ptr) { > std::memcpy(curPtr, jliLibPath.c_str(), count); > ptr->jliLibPath = curPtr; > } > curPtr += count; > } while (false); // <---- here > > There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) tools/jpackage There are also instances of "while(0)" (without space) in app.cpp, tstrings.cpp. and ErrorHandling.h ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From weijun at openjdk.java.net Mon Feb 8 14:42:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 8 Feb 2021 14:42:44 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes in Apache Santuario The other security-related code changes look good to me. src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49: > 47: throws IOException > 48: { > 49: return is.readAllBytes(); This is also from Apache Santuario. It's better to keep it unchanged. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jlaskey at openjdk.java.net Mon Feb 8 15:01:47 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 8 Feb 2021 15:01:47 GMT Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2] In-Reply-To: References: Message-ID: <96VcSCo12SWED8nwd5N7wda6juUXH3RxGMHW_XIjVWk=.f7f7594c-d60c-415f-b0bd-e98fbe60b62e@github.com> On Wed, 3 Feb 2021 01:29:02 GMT, Bo Zhang wrote: >> Previously, `ImageBufferCache` contains a ThreadLocal field which holds >> strong reference to `ImageBufferCache$BufferReference.class`. When loaded >> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader` >> in memory forever and never being GCed. >> >> The fix replace the old `ImageBufferCache$BufferReference` class with >> `WeakReference`, which is verified by provided test. > > Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2307 From shade at openjdk.java.net Mon Feb 8 15:25:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 15:25:02 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v2] In-Reply-To: References: Message-ID: > After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." > > int initJvmlLauncherData(JvmlLauncherData* ptr) const { > // Store path to JLI library just behind JvmlLauncherData header. > char* curPtr = reinterpret_cast(ptr + 1); > do { > const size_t count = sizeof(char) > * (jliLibPath.size() + 1 /* trailing zero */); > if (ptr) { > std::memcpy(curPtr, jliLibPath.c_str(), count); > ptr->jliLibPath = curPtr; > } > curPtr += count; > } while (false); // <---- here > > There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) tools/jpackage Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: More cleanup in tstrings.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2454/files - new: https://git.openjdk.java.net/jdk/pull/2454/files/92873eee..d895c44a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2454/head:pull/2454 PR: https://git.openjdk.java.net/jdk/pull/2454 From shade at openjdk.java.net Mon Feb 8 15:25:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 8 Feb 2021 15:25:03 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:31:32 GMT, Andy Herrick wrote: > There are also instances of "while(0)" (without space) in app.cpp, tstrings.cpp. and ErrorHandling.h Right. I removed more things in `tstrings.cpp`, but in other places, `while(0)` are in `#define`-s, and that is one place where those make sense: they guard from syntax/semantic errors during macro expansion. ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From herrick at openjdk.java.net Mon Feb 8 15:31:42 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 8 Feb 2021 15:31:42 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v2] In-Reply-To: References: Message-ID: <5VMqmTohDGsnvDpduLhSqpCIYsS_ddKCIM0iIMhLpjM=.4ba82c89-35dd-47dc-963e-20cc770e0b04@github.com> On Mon, 8 Feb 2021 15:25:02 GMT, Aleksey Shipilev wrote: >> After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." >> >> int initJvmlLauncherData(JvmlLauncherData* ptr) const { >> // Store path to JLI library just behind JvmlLauncherData header. >> char* curPtr = reinterpret_cast(ptr + 1); >> do { >> const size_t count = sizeof(char) >> * (jliLibPath.size() + 1 /* trailing zero */); >> if (ptr) { >> std::memcpy(curPtr, jliLibPath.c_str(), count); >> ptr->jliLibPath = curPtr; >> } >> curPtr += count; >> } while (false); // <---- here >> >> There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) tools/jpackage > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup in tstrings.cpp OK - looks good to me. ------------- Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2454 From jboes at openjdk.java.net Mon Feb 8 16:21:56 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 8 Feb 2021 16:21:56 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v7] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29: > 27: > 28: import java.io.ByteArrayInputStream; > 29: import java.io.IOException; The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From asemenyuk at openjdk.java.net Mon Feb 8 16:22:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 8 Feb 2021 16:22:41 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 08:49:17 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports as new warning after JDK-8254702: > > This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. > > char* getJvmLauncherLibPath(void) { > ... > if (PACKAGE_TYPE_RPM == pkg->type) { > pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; > } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here > pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; > > Seems like an obvious typo. > > Additional tests: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From asemenyuk at openjdk.java.net Mon Feb 8 16:23:42 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 8 Feb 2021 16:23:42 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v2] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 15:25:02 GMT, Aleksey Shipilev wrote: >> After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." >> >> int initJvmlLauncherData(JvmlLauncherData* ptr) const { >> // Store path to JLI library just behind JvmlLauncherData header. >> char* curPtr = reinterpret_cast(ptr + 1); >> do { >> const size_t count = sizeof(char) >> * (jliLibPath.size() + 1 /* trailing zero */); >> if (ptr) { >> std::memcpy(curPtr, jliLibPath.c_str(), count); >> ptr->jliLibPath = curPtr; >> } >> curPtr += count; >> } while (false); // <---- here >> >> There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) tools/jpackage > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup in tstrings.cpp Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From jboes at openjdk.java.net Mon Feb 8 16:42:42 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 8 Feb 2021 16:42:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > The other security-related code changes look good to me. I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From redestad at openjdk.java.net Mon Feb 8 16:44:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 16:44:42 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile In-Reply-To: References: <2fdyXJvAqfSWA6lM0iifm14gc2eVVekRqovVDapJh2g=.d0a51bd0-58b7-402a-9325-beb83e09d4c7@github.com> Message-ID: On Mon, 8 Feb 2021 14:25:45 GMT, Christoph Langer wrote: >> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 87: >> >>> 85: * path is not a JAR file or some other error occurs. >>> 86: */ >>> 87: public static boolean isClassPathAttributePresent(String path) { >> >> Is isClassPathAttributePresent used anywhere? I remember we added VMSupport for use by JVMTI and the attach mechanism but I don't see any usages of this method now. > > Seems you're right. My search for "isClassPathAttributePresent" also didn't yield anything. So why not remove it altogether...? Removing it sounds good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From alanb at openjdk.java.net Mon Feb 8 16:52:50 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 8 Feb 2021 16:52:50 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v4] In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 20:16:08 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > Michael McMahon 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 11 additional commits since the last revision: > > - Merge branch 'master' into 8252971-socket-attributes > - add specific check for unix domain socket > - Merge branch 'master' into 8252971-socket-attributes > - update > - update > - update > - update > - update after Alan's first review > - Merge branch 'master' into 8252971-socket-attributes > - test update > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/77ac60d6...746b4762 src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 346: > 344: Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT), > 345: 0L); > 346: fc.close(); The new version looks a bit strange. As I read it, the attempt to open the file fails with ERROR_CANT_ACCESS_FILE so you then check test if the file is a socket file. That succeeds so we should be done. What is the reason for opening the file again? src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862: > 860: * and a handle to the socket file if it is. > 861: */ > 862: private long openSocketForReadAttributeAccess() { The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From naoto at openjdk.java.net Mon Feb 8 17:42:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 8 Feb 2021 17:42:42 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com> On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 Looks good to me. I initially thought of the same impression as Alan's, i.e., enumerating all charsets is not that common (in fact, same applies to Locale, and I once explored usages and it ended all up in test cases), but if real apps are using it, this is the right way to do so. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2449 From martin at openjdk.java.net Mon Feb 8 18:12:43 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 8 Feb 2021 18:12:43 GMT Subject: RFR: 8259074: regex benchmarks and tests [v5] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 13:10:29 GMT, Claes Redestad wrote: >> Martin Buchholz has updated the pull request incrementally with one additional commit since the last revision: >> >> fix imports > > Marked as reviewed by redestad (Reviewer). @cl4es Your comment sent me back to jmh re-education camp. I never looked at warmup iterations numbers before, but I now see they can be very useful for eyeballing how long warmup takes. Very JVM-dependent of course. In practice I will stick with my rule of thumb that 10 seconds of warmup is good enough for any simple program, and that happens to be the JMH warmup time default. OTOH I think more than one warmup iteration is overkill for most benchmarks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From martin at openjdk.java.net Mon Feb 8 18:12:45 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Mon, 8 Feb 2021 18:12:45 GMT Subject: Integrated: 8259074: regex benchmarks and tests In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 03:15:56 GMT, Martin Buchholz wrote: > 8259074: regex benchmarks and tests This pull request has now been integrated. Changeset: 351d7888 Author: Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/351d7888 Stats: 483 lines in 5 files changed: 473 ins; 7 del; 3 mod 8259074: regex benchmarks and tests Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/1940 From redestad at openjdk.java.net Mon Feb 8 18:48:45 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 18:48:45 GMT Subject: Integrated: 8261254: Initialize charset mapping data lazily In-Reply-To: References: Message-ID: On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote: > This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 92c6e6df Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/92c6e6df Stats: 274 lines in 21 files changed: 24 ins; 59 del; 191 mod 8261254: Initialize charset mapping data lazily Reviewed-by: alanb, jkuhn, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From redestad at openjdk.java.net Mon Feb 8 18:48:43 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 8 Feb 2021 18:48:43 GMT Subject: RFR: 8261254: Initialize charset mapping data lazily In-Reply-To: <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com> References: <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com> Message-ID: On Mon, 8 Feb 2021 17:40:00 GMT, Naoto Sato wrote: >> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets. >> >> Testing: tier1-3 > > Looks good to me. I initially thought of the same impression as Alan's, i.e., enumerating all charsets is not that common (in fact, same applies to Locale, and I once explored usages and it ended all up in test cases), but if real apps are using it, this is the right way to do so. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2449 From hannesw at openjdk.java.net Mon Feb 8 18:53:42 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 8 Feb 2021 18:53:42 GMT Subject: RFR: 8198540: Dynalink leaks memory when generating type converters [v7] In-Reply-To: References: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> Message-ID: On Sun, 7 Feb 2021 15:45:00 GMT, Peter Levart wrote: >> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename ClassLoaderRelation to RetentionDirection; it is better self-documenting this way. > > I think this looks good Attila. > @plevart would you be then be okay with approving this PR? Also, @hns or @sundararajana can I maybe get a review from either of you? @szegedi I've looked at the BiClassValue code and it looks good to me. If that's ok for you I'll review the rest of the PR tomorrow morning. ------------- PR: https://git.openjdk.java.net/jdk/pull/1918 From isipka at openjdk.java.net Mon Feb 8 20:12:03 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 8 Feb 2021 20:12:03 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v5] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java ------------- Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=04 Stats: 444 lines in 6 files changed: 139 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:50:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:50:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.management/share/classes/javax/management/loading/MLet.java line 1147: > >> 1145: .toFile(); >> 1146: file.deleteOnExit(); >> 1147: Files.copy(is, file.toPath()); > > One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code). > > The code that follows checks if the file exists, this will always be true when Files.copy succeeds. fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:54:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:54:47 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v7] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes wrote: >> Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29: > >> 27: >> 28: import java.io.ByteArrayInputStream; >> 29: import java.io.IOException; > > The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable. done ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:54:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:54:48 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes in Apache Santuario > > src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49: > >> 47: throws IOException >> 48: { >> 49: return is.readAllBytes(); > > This is also from Apache Santuario. It's better to keep it unchanged. reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 8 20:58:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 8 Feb 2021 20:58:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo fix review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/94e99817..6a8a3ae6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07-08 Stats: 29 lines in 10 files changed: 16 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+471021+marschall at openjdk.java.net Mon Feb 8 21:21:44 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 8 Feb 2021 21:21:44 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > fix review comments src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230: > 228: // Copy the entire input stream into an InputStream that does > 229: // support mark > 230: is = new ByteArrayInputStream(is.readAllBytes()); I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do: PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From bpb at openjdk.java.net Mon Feb 8 21:46:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 21:46:56 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5] In-Reply-To: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com> References: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com> Message-ID: On Tue, 26 Jan 2021 18:22:02 GMT, Philippe Marschall wrote: >> Implement three optimiztations for Reader.read(CharBuffer) >> >> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. >> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. >> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. >> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. > > Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: > > Limit amount read to avoid BufferOverflowException > > - limit the amount read > - add tests src/java.base/share/classes/java/io/Reader.java line 194: > 192: nread = this.read(cbuf, off, len); > 193: if (nread > 0) > 194: target.position(target.position() + nread); As `target` is mutable, I think you would do better to change lines 189-194 to something like: char cbuf[] = target.array(); int pos = target.position(); int rem = target.limit() - pos; if (rem <= 0) return -1; int off = target.arrayOffset() + pos; nread = this.read(cbuf, off, rem); if (nread > 0) target.position(pos + nread); ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From bpb at openjdk.java.net Mon Feb 8 21:46:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 21:46:55 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3] In-Reply-To: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com> References: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com> Message-ID: <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com> On Tue, 5 Jan 2021 17:44:20 GMT, Philippe Marschall wrote: >> Implement three optimiztations for Reader.read(CharBuffer) >> >> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. >> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. >> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. >> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. > > Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years src/java.base/share/classes/java/io/Reader.java line 198: > 196: } else { > 197: int remaining = target.remaining(); > 198: char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)]; As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help? ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From naoto at openjdk.java.net Mon Feb 8 21:47:53 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 8 Feb 2021 21:47:53 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out Message-ID: Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. ------------- Commit messages: - 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out Changes: https://git.openjdk.java.net/jdk/pull/2465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261279 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2465/head:pull/2465 PR: https://git.openjdk.java.net/jdk/pull/2465 From michaelm at openjdk.java.net Mon Feb 8 21:51:44 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 21:51:44 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v4] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 16:48:44 GMT, Alan Bateman wrote: >> Michael McMahon 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 11 additional commits since the last revision: >> >> - Merge branch 'master' into 8252971-socket-attributes >> - add specific check for unix domain socket >> - Merge branch 'master' into 8252971-socket-attributes >> - update >> - update >> - update >> - update >> - update after Alan's first review >> - Merge branch 'master' into 8252971-socket-attributes >> - test update >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/6a98ca22...746b4762 > > src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 346: > >> 344: Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT), >> 345: 0L); >> 346: fc.close(); > > The new version looks a bit strange. As I read it, the attempt to open the file fails with ERROR_CANT_ACCESS_FILE so you then check test if the file is a socket file. That succeeds so we should be done. What is the reason for opening the file again? I added the test of the socket reparse tag to be 100% sure that we weren't returning false positives for other cases of ERROR_CANT_ACCESS_FILE. But, otherwise, I thought I had to open the file the same way as before to be sure that it is readable. If checking the reparse tag is sufficient then great, that simplifies the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From bpb at openjdk.java.net Mon Feb 8 21:53:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 21:53:53 GMT Subject: RFR: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math [v3] In-Reply-To: <-NcTC711LHxE8gEz1rnN6cHko6tW-BBcRJPUJ5eCfdg=.d4d31092-15cf-45ee-9a71-a42b95e7a08c@github.com> References: <-NcTC711LHxE8gEz1rnN6cHko6tW-BBcRJPUJ5eCfdg=.d4d31092-15cf-45ee-9a71-a42b95e7a08c@github.com> Message-ID: On Sun, 7 Feb 2021 00:45:03 GMT, Joe Darcy wrote: >> Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. >> >> Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. >> >> If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. >> >> There is no intention at the moment to change the behavior of pow to align with IEEE 754. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review comments. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2395 From darcy at openjdk.java.net Mon Feb 8 21:53:55 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 8 Feb 2021 21:53:55 GMT Subject: Integrated: 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 02:08:12 GMT, Joe Darcy wrote: > Recent revisions of the IEEE 754 floating-point standard have added guidance on how typical math library methods (sin, cos, tan, etc.) should behave in terms of their general quality of implementation as well as on special values. > > Other than the pow methods, for the recommended operations listed by IEEE 754 that the Java math library already includes, the special cases that are specified by Java are the same as those specified by IEEE 754, except for the pow method. IEEE 754 calls out some special cases not explicitly listed in the Java specs. This changeset adds those special cases to the spec and adds tests of the the special cases if not already present. > > If method "Foo" already had a regression test, new cases were added it it. Otherwise, a new test was added to cover the special cases of several methods. > > There is no intention at the moment to change the behavior of pow to align with IEEE 754. This pull request has now been integrated. Changeset: 2fd8ed02 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/2fd8ed02 Stats: 264 lines in 5 files changed: 243 ins; 0 del; 21 mod 8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2395 From lancea at openjdk.java.net Mon Feb 8 21:55:42 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 8 Feb 2021 21:55:42 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote: > Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From bpb at openjdk.java.net Mon Feb 8 21:55:42 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 21:55:42 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: <6Ks856fd96fiprHkzJ-4CzDpdfhSBMvTw0D8TngJ7SY=.b5678a91-b11a-4ee5-94ac-c7797aac2479@github.com> On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote: > Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From michaelm at openjdk.java.net Mon Feb 8 22:06:26 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 22:06:26 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v4] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 16:50:02 GMT, Alan Bateman wrote: >> Michael McMahon 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 11 additional commits since the last revision: >> >> - Merge branch 'master' into 8252971-socket-attributes >> - add specific check for unix domain socket >> - Merge branch 'master' into 8252971-socket-attributes >> - update >> - update >> - update >> - update >> - update after Alan's first review >> - Merge branch 'master' into 8252971-socket-attributes >> - test update >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4e1be4ef...746b4762 > > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862: > >> 860: * and a handle to the socket file if it is. >> 861: */ >> 862: private long openSocketForReadAttributeAccess() { > > The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE. Okay ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Mon Feb 8 22:06:20 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 22:06:20 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v5] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/746b4762..f644e939 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=03-04 Stats: 29 lines in 2 files changed: 2 ins; 16 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Mon Feb 8 22:23:43 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 22:23:43 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v4] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:59:53 GMT, Michael McMahon wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862: >> >>> 860: * and a handle to the socket file if it is. >>> 861: */ >>> 862: private long openSocketForReadAttributeAccess() { >> >> The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE. > > Okay Actually, there's a mistake in the current latest version (04). Should have tested it before pushing. Will push update shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From bpb at openjdk.java.net Mon Feb 8 22:25:02 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 22:25:02 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:22:55 GMT, Brian Burkhalter wrote: > Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. ping ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From asemenyuk at openjdk.java.net Mon Feb 8 22:30:53 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Mon, 8 Feb 2021 22:30:53 GMT Subject: RFR: 8223188: Consider rewriting in C++ or moving to ".c" files Message-ID: Remove needless `#ifdef __cplusplus` from .cpp sources ------------- Commit messages: - 8223188: Consider rewriting in C++ or moving to ".c" files Changes: https://git.openjdk.java.net/jdk/pull/2466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223188 Stats: 10 lines in 2 files changed: 0 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2466/head:pull/2466 PR: https://git.openjdk.java.net/jdk/pull/2466 From michaelm at openjdk.java.net Mon Feb 8 22:40:04 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 22:40:04 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v6] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: fix mistake in last push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/f644e939..c1fd3565 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From naoto at openjdk.java.net Mon Feb 8 22:54:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 8 Feb 2021 22:54:44 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:22:55 GMT, Brian Burkhalter wrote: > Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. src/java.base/share/classes/java/io/FilterReader.java line 81: > 79: * {@inheritDoc} > 80: * > 81: * @throws IllegalArgumentException If {@code n} is negative and the Does this have to be different from the `Reader.skip()`'s description? Since the contained reader implements `Reader` (throws IAE as a contract), that condition after `and` is always true? ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From michaelm at openjdk.java.net Mon Feb 8 22:54:56 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 8 Feb 2021 22:54:56 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v7] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/c1fd3565..92031fbc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=05-06 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From bpb at openjdk.java.net Mon Feb 8 23:00:58 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 8 Feb 2021 23:00:58 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:51:43 GMT, Naoto Sato wrote: >> Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. > > src/java.base/share/classes/java/io/FilterReader.java line 81: > >> 79: * {@inheritDoc} >> 80: * >> 81: * @throws IllegalArgumentException If {@code n} is negative and the > > Does this have to be different from the `Reader.skip()`'s description? Since the contained reader implements `Reader` (throws IAE as a contract), that condition after `and` is always true? This came from some `Reader`s, e.g., `CharArrayReader`, `StringReader`, overriding `skip()` _not_ to throw an IAE. But at the specification level perhaps this should not be recognized. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From herrick at openjdk.java.net Mon Feb 8 23:07:43 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Mon, 8 Feb 2021 23:07:43 GMT Subject: RFR: 8223188: Consider rewriting in C++ or moving to ".c" files In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From naoto at openjdk.java.net Mon Feb 8 23:22:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 8 Feb 2021 23:22:44 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:58:13 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/FilterReader.java line 81: >> >>> 79: * {@inheritDoc} >>> 80: * >>> 81: * @throws IllegalArgumentException If {@code n} is negative and the >> >> Does this have to be different from the `Reader.skip()`'s description? Since the contained reader implements `Reader` (throws IAE as a contract), that condition after `and` is always true? > > This came from some `Reader`s, e.g., `CharArrayReader`, `StringReader`, overriding `skip()` _not_ to throw an IAE. But at the specification level perhaps this should not be recognized. Makes sense. Then I would let CSR decide whether to include the description or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From joehw at openjdk.java.net Mon Feb 8 23:44:41 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 8 Feb 2021 23:44:41 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:52:45 GMT, Lance Andersen wrote: >> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. > > Marked as reviewed by lancea (Reviewer). The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run. ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From naoto at openjdk.java.net Tue Feb 9 00:07:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 00:07:41 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 23:42:04 GMT, Joe Wang wrote: >> Marked as reviewed by lancea (Reviewer). > > The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). > > Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run. As of JDK15, there are more than 800 locales, so reducing the samples down to 30 makes it less than 4% of the original (~20,000ms on that machine). But I agree that the test took too long than my environment too. Could be a very slow machine. As to other tests calling available locales, the reason this test took a long time is that the loop multiplies with the number of time zones which is also huge (600+), so it would be less likely that other locale tests cause timeouts. ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From almatvee at openjdk.java.net Tue Feb 9 00:08:42 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 9 Feb 2021 00:08:42 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v2] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 15:25:02 GMT, Aleksey Shipilev wrote: >> After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." >> >> int initJvmlLauncherData(JvmlLauncherData* ptr) const { >> // Store path to JLI library just behind JvmlLauncherData header. >> char* curPtr = reinterpret_cast(ptr + 1); >> do { >> const size_t count = sizeof(char) >> * (jliLibPath.size() + 1 /* trailing zero */); >> if (ptr) { >> std::memcpy(curPtr, jliLibPath.c_str(), count); >> ptr->jliLibPath = curPtr; >> } >> curPtr += count; >> } while (false); // <---- here >> >> There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) tools/jpackage > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More cleanup in tstrings.cpp Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From bpb at openjdk.java.net Tue Feb 9 00:17:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 9 Feb 2021 00:17:00 GMT Subject: RFR: 8261306: ServiceLoader documentation has malformed Unicode escape Message-ID: Please review this really small correction to the class level documentation of `java.util.ServiceLoader`. ------------- Commit messages: - 8261306: ServiceLoader documentation has malformed Unicode escape Changes: https://git.openjdk.java.net/jdk/pull/2468/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2468&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261306 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2468.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2468/head:pull/2468 PR: https://git.openjdk.java.net/jdk/pull/2468 From almatvee at openjdk.java.net Tue Feb 9 00:23:40 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 9 Feb 2021 00:23:40 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: References: Message-ID: <6BCJ2YSNkCvyNezMKtpkWmXFuO1Pxxvm0JacqXy1l0o=.0e06a2b8-d833-4e83-9fb9-cc8924d663df@github.com> On Mon, 8 Feb 2021 08:49:17 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports as new warning after JDK-8254702: > > This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. > > char* getJvmLauncherLibPath(void) { > ... > if (PACKAGE_TYPE_RPM == pkg->type) { > pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; > } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here > pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; > > Seems like an obvious typo. > > Additional tests: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From lancea at openjdk.java.net Tue Feb 9 00:27:41 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 9 Feb 2021 00:27:41 GMT Subject: RFR: 8261306: ServiceLoader documentation has malformed Unicode escape In-Reply-To: References: Message-ID: <6bX7FEfbrPUh-GeglHoC2AFdGrVLVxcR6x566Ns3gXo=.88d9618d-aadf-42e0-818b-592cf2dfa472@github.com> On Tue, 9 Feb 2021 00:11:52 GMT, Brian Burkhalter wrote: > Please review this really small correction to the class level documentation of `java.util.ServiceLoader`. I think this is fine. You could also probably use &num given this is HTML I believe ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2468 From iris at openjdk.java.net Tue Feb 9 00:48:44 2021 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 9 Feb 2021 00:48:44 GMT Subject: RFR: 8261306: ServiceLoader documentation has malformed Unicode escape In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 00:11:52 GMT, Brian Burkhalter wrote: > Please review this really small correction to the class level documentation of `java.util.ServiceLoader`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2468 From almatvee at openjdk.java.net Tue Feb 9 01:00:41 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 9 Feb 2021 01:00:41 GMT Subject: RFR: 8223188: Consider rewriting in C++ or moving to ".c" files In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From naoto at openjdk.java.net Tue Feb 9 01:32:39 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 01:32:39 GMT Subject: RFR: 8261306: ServiceLoader documentation has malformed Unicode escape In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 00:11:52 GMT, Brian Burkhalter wrote: > Please review this really small correction to the class level documentation of `java.util.ServiceLoader`. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2468 From joehw at openjdk.java.net Tue Feb 9 01:40:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 9 Feb 2021 01:40:43 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote: > Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From joehw at openjdk.java.net Tue Feb 9 01:40:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 9 Feb 2021 01:40:43 GMT Subject: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 00:04:44 GMT, Naoto Sato wrote: >> The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). >> >> Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run. > > As of JDK15, there are more than 800 locales, so reducing the samples down to 30 makes it less than 4% of the original (~20,000ms on that machine). But I agree that the test took too long than my environment too. Could be a very slow machine. > As to other tests calling available locales, the reason this test took a long time is that the loop multiplies with the number of time zones which is also huge (600+), so it would be less likely that other locale tests cause timeouts. I see. I didn't know locales had gone from 160 to 800! All the more reason to set a limit. Rerun with jdk 16, limit(30) does make it a breeze comparing to that without (which made my machine start to spin). 20,000ms is reasonable on a slower machine with a debug build. ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From iklam at openjdk.java.net Tue Feb 9 04:05:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 04:05:40 GMT Subject: RFR: 8223188: Consider rewriting in C++ or moving to ".c" files In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources The Bug Synopsis of 'Consider rewriting in C++ or moving to ".c" files' is unclear. I would request that the Bug Synopsis to be changed to "removed unnecessary #ifdef __cplusplus" before integrating this PR. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2466 From darcy at openjdk.java.net Tue Feb 9 06:47:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 9 Feb 2021 06:47:53 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods Message-ID: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. ------------- Commit messages: - Merge branch 'master' into 8261123 - Initial changes for JDK-8261123. Changes: https://git.openjdk.java.net/jdk/pull/2471/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261123 Stats: 80 lines in 4 files changed: 38 ins; 14 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From mbaesken at openjdk.java.net Tue Feb 9 08:30:54 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 08:30:54 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile [v2] In-Reply-To: References: Message-ID: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove isClassPathAttributePresent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2429/files - new: https://git.openjdk.java.net/jdk/pull/2429/files/f90aa961..1fc9b8c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2429&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2429&range=00-01 Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2429.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2429/head:pull/2429 PR: https://git.openjdk.java.net/jdk/pull/2429 From mbaesken at openjdk.java.net Tue Feb 9 08:30:55 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 08:30:55 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile [v2] In-Reply-To: References: <2fdyXJvAqfSWA6lM0iifm14gc2eVVekRqovVDapJh2g=.d0a51bd0-58b7-402a-9325-beb83e09d4c7@github.com> Message-ID: <7snJ0afTys5EmfPDimMNfEvNm0nuzLOdqNZuueVj9dM=.8b748e6c-2f02-4d3c-910a-d95f5069f5dc@github.com> On Mon, 8 Feb 2021 16:41:44 GMT, Claes Redestad wrote: >> Seems you're right. My search for "isClassPathAttributePresent" also didn't yield anything. So why not remove it altogether...? > > Removing it sounds good. hi, I removed isClassPathAttributePresent . ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From redestad at openjdk.java.net Tue Feb 9 08:34:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 08:34:42 GMT Subject: RFR: JDK-8261237: isClassPathAttributePresent use try with resources with JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 08:30:54 GMT, Matthias Baesken wrote: >> Hello, >> Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. >> See also the Sonar check result : >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG >> >> public static boolean isClassPathAttributePresent(String path) { >> try { >> Manifest man = (new JarFile(path)).getManifest(); >> Use try-with-resources or close this "JarFile" in a "finally" clause. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove isClassPathAttributePresent Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From alanb at openjdk.java.net Tue Feb 9 08:51:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 9 Feb 2021 08:51:53 GMT Subject: RFR: JDK-8261237: remove isClassPathAttributePresent method [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 08:30:54 GMT, Matthias Baesken wrote: >> Hello, >> Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. >> See also the Sonar check result : >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG >> >> public static boolean isClassPathAttributePresent(String path) { >> try { >> Manifest man = (new JarFile(path)).getManifest(); >> Use try-with-resources or close this "JarFile" in a "finally" clause. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove isClassPathAttributePresent Removing it looks fine. Can you change the description of JDK-8261237 to reflect the change. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2429 From clanger at openjdk.java.net Tue Feb 9 08:51:57 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 9 Feb 2021 08:51:57 GMT Subject: RFR: JDK-8261237: remove isClassPathAttributePresent method [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 08:30:54 GMT, Matthias Baesken wrote: >> Hello, >> Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. >> See also the Sonar check result : >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG >> >> public static boolean isClassPathAttributePresent(String path) { >> try { >> Manifest man = (new JarFile(path)).getManifest(); >> Use try-with-resources or close this "JarFile" in a "finally" clause. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove isClassPathAttributePresent Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From shade at openjdk.java.net Tue Feb 9 08:52:17 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 08:52:17 GMT Subject: RFR: JDK-8261237: remove isClassPathAttributePresent method [v2] In-Reply-To: References: Message-ID: <9GViSqVTitNrg8SlwgYBwz788XZP-tm54GWVBuN5OdY=.c5b9a7a9-8913-481b-83cf-e94ad1f7af12@github.com> On Tue, 9 Feb 2021 08:30:54 GMT, Matthias Baesken wrote: >> Hello, >> Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. >> See also the Sonar check result : >> >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG >> >> public static boolean isClassPathAttributePresent(String path) { >> try { >> Manifest man = (new JarFile(path)).getManifest(); >> Use try-with-resources or close this "JarFile" in a "finally" clause. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove isClassPathAttributePresent Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From shade at openjdk.java.net Tue Feb 9 08:58:23 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 08:58:23 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v3] In-Reply-To: References: Message-ID: > After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." > > int initJvmlLauncherData(JvmlLauncherData* ptr) const { > // Store path to JLI library just behind JvmlLauncherData header. > char* curPtr = reinterpret_cast(ptr + 1); > do { > const size_t count = sizeof(char) > * (jliLibPath.size() + 1 /* trailing zero */); > if (ptr) { > std::memcpy(curPtr, jliLibPath.c_str(), count); > ptr->jliLibPath = curPtr; > } > curPtr += count; > } while (false); // <---- here > > There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) tools/jpackage Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Fix Windows build failure: illegal break (where while loop used to be) - Merge branch 'master' into JDK-8261300-jpackage-while-0 - More cleanup in tstrings.cpp - Replace with {} ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2454/files - new: https://git.openjdk.java.net/jdk/pull/2454/files/d895c44a..535024b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2454&range=01-02 Stats: 3817 lines in 211 files changed: 2333 ins; 236 del; 1248 mod Patch: https://git.openjdk.java.net/jdk/pull/2454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2454/head:pull/2454 PR: https://git.openjdk.java.net/jdk/pull/2454 From shade at openjdk.java.net Tue Feb 9 08:59:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 08:59:11 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: <6BCJ2YSNkCvyNezMKtpkWmXFuO1Pxxvm0JacqXy1l0o=.0e06a2b8-d833-4e83-9fb9-cc8924d663df@github.com> References: <6BCJ2YSNkCvyNezMKtpkWmXFuO1Pxxvm0JacqXy1l0o=.0e06a2b8-d833-4e83-9fb9-cc8924d663df@github.com> Message-ID: On Tue, 9 Feb 2021 00:20:25 GMT, Alexander Matveev wrote: >> SonarCloud instance reports as new warning after JDK-8254702: >> >> This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. >> >> char* getJvmLauncherLibPath(void) { >> ... >> if (PACKAGE_TYPE_RPM == pkg->type) { >> pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; >> } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here >> pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; >> >> Seems like an obvious typo. >> >> Additional tests: >> - [x] Linux x86_64 (Ubuntu) `tools/jpackage` > > Marked as reviewed by almatvee (Committer). Ah. Still looking for formal Reviewer to ack. ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From shade at openjdk.java.net Tue Feb 9 09:04:30 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 09:04:30 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: <6IJUt64f_27mx-30qC7JMcPh_x3gg07tX5qUsjZMpOg=.720fb519-9a2c-4929-84dc-933e2a022c1a@github.com> References: <6IJUt64f_27mx-30qC7JMcPh_x3gg07tX5qUsjZMpOg=.720fb519-9a2c-4929-84dc-933e2a022c1a@github.com> Message-ID: <-INMEHHKfXKm6r5NnRzrx_0_9NrwdPT6jd9fN_l7fX8=.c7e7fc81-7ba9-4c59-8034-c76204c94273@github.com> On Mon, 8 Feb 2021 10:34:06 GMT, Thomas Stuefe wrote: >> SonarCloud instance reports a new warning after JDK-8254702: >> "Use of memory after it is freed" >> >> char* getJvmLauncherLibPath(void) { >> ... >> popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, >> &launcherLibPath); >> if (popenStatus) { >> free(launcherLibPath); <---- frees here >> goto cleanup; >> } >> } >> >> cleanup: >> free(modulePath); >> freePackageDesc(pkg); >> >> return launcherLibPath; <--- here >> } >> >> We need to null it out before returning. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) `tools/jpackage` > > Marked as reviewed by stuefe (Reviewer). jpackage reviewers, please? @andyherrick? ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From shade at openjdk.java.net Tue Feb 9 09:23:30 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 09:23:30 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 2 Feb 2021 15:38:01 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings > > STDERR: > java.lang.OutOfMemoryError: Required length exceeds implementation limit > at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) > at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) > at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) > at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) > at HugeCapacity.testLatin1(HugeCapacity.java:49) > at HugeCapacity.main(HugeCapacity.java:37) > > I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. > > Additional testing: > - [x] Linux x86_64, affected test (default), passes > - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes > - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes Anyone? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From stefank at openjdk.java.net Tue Feb 9 09:34:38 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 9 Feb 2021 09:34:38 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12] In-Reply-To: References: Message-ID: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com> On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Update signal handler part for debugger Thanks for cleaning out WXWriteFromExecSetter. src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 52: > 50: > 51: int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) { > 52: // Enable WXWrite: the function is called direclty from nmethod_entry_barrier direclty -> directly src/hotspot/share/runtime/threadWXSetters.hpp line 28: > 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP > 27: > 28: #include "runtime/thread.inline.hpp" This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp See the Source Files section in: https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html src/hotspot/share/runtime/thread.hpp line 848: > 846: void init_wx(); > 847: WXMode enable_wx(WXMode new_state); > 848: #endif // __APPLE__ && AARCH64 Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions. src/hotspot/share/runtime/thread.cpp line 2515: > 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { > 2514: // Enable WXWrite: called directly from interpreter native wrapper. > 2515: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread)); FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version: ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) { MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {} void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp) With that said, I'm fine with taking this discussion as a follow-up. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+1059453+fleshgrinder at openjdk.java.net Tue Feb 9 10:14:30 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Tue, 9 Feb 2021 10:14:30 GMT Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput In-Reply-To: References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> Message-ID: On Tue, 12 Jan 2021 07:26:44 GMT, Richard Fussenegger wrote: >> Requested feedback on the API addition/modifications: >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072530.html > > Active Active ------------- PR: https://git.openjdk.java.net/jdk/pull/1465 From hannesw at openjdk.java.net Tue Feb 9 10:59:31 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 9 Feb 2021 10:59:31 GMT Subject: RFR: 8198540: Dynalink leaks memory when generating type converters [v7] In-Reply-To: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> References: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> Message-ID: On Sun, 10 Jan 2021 17:04:19 GMT, Attila Szegedi wrote: >> _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_ >> >> I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons. >> >> Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?) >> >> ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution. >> >> And it exists! I ended up replacing the `ClassValue>` construct with a ground-up implementation of `BiClassValue`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction, Class, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders. >> >> And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way. >> >> There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them. > > Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: > > Rename ClassLoaderRelation to RetentionDirection; it is better self-documenting this way. Nice work as ever, Attila. Looks good to me. ------------- Marked as reviewed by hannesw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1918 From mbaesken at openjdk.java.net Tue Feb 9 11:22:29 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 11:22:29 GMT Subject: Integrated: JDK-8261237: remove isClassPathAttributePresent method In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote: > Hello, > Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a related finally clause or try with resources. That should better be changed. > See also the Sonar check result : > > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=false&severities=BLOCKER&types=BUG > > public static boolean isClassPathAttributePresent(String path) { > try { > Manifest man = (new JarFile(path)).getManifest(); > Use try-with-resources or close this "JarFile" in a "finally" clause. This pull request has now been integrated. Changeset: 8ebed284 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/8ebed284 Stats: 20 lines in 1 file changed: 0 ins; 19 del; 1 mod 8261237: remove isClassPathAttributePresent method Reviewed-by: shade, clanger, redestad, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2429 From github.com+471021+marschall at openjdk.java.net Tue Feb 9 11:42:34 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 9 Feb 2021 11:42:34 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > fix review comments src/java.base/share/classes/java/util/jar/JarInputStream.java line 93: > 91: if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) { > 92: man = new Manifest(); > 93: byte[] bytes = new BufferedInputStream(this).readAllBytes(); I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7. In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From shade at openjdk.java.net Tue Feb 9 12:50:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 12:50:40 GMT Subject: RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods Message-ID: Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). Interpreter-only "Hello World": Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) OpenLiberty startup: Before: 2.296, 2.281, 2.291 (seconds) After: 2.254, 2.267, 2.272 (seconds) Additional tests: - [x] Linux `tier1` default (passes) - [x] Linux `tier1` `-XX:-CompactStrings` ------------- Commit messages: - Merge branch 'master' into JDK-8260710-string-inline - Merge branch 'master' into JDK-8260710-string-inline - Initial prototype Changes: https://git.openjdk.java.net/jdk/pull/2334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260710 Stats: 173 lines in 5 files changed: 5 ins; 48 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/2334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2334/head:pull/2334 PR: https://git.openjdk.java.net/jdk/pull/2334 From redestad at openjdk.java.net Tue Feb 9 13:09:27 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 13:09:27 GMT Subject: RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 13:11:52 GMT, Aleksey Shipilev wrote: > Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. > > This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. > > The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. > > On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). > > Interpreter-only "Hello World": > > Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) > 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) > 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) > > Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) > 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) > 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) > > > OpenLiberty startup: > > Before: 2.296, 2.281, 2.291 (seconds) > After: 2.254, 2.267, 2.272 (seconds) > > Additional tests: > - [x] Linux `tier1` default (passes) > - [x] Linux `tier1` `-XX:-CompactStrings` Looks good to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2334 From redestad at openjdk.java.net Tue Feb 9 13:27:12 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 13:27:12 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad wrote: > This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) > > Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. > > Testing: tier1-3, manual runs of sun.nio.cs tests `StringDecode.WithCharset.decodeCharsetName` microbenchmark runs pre-JDK-8259842: Benchmark (charsetName) Mode Cnt Score Error Units decodeCharsetName x-ISO-2022-CN-GB avgt 5 756.293 ? 56.082 ns/op decodeCharsetName:?gc.alloc.rate.norm x-ISO-2022-CN-GB avgt 5 488.040 ? 0.013 B/op decodeCharsetName ISO-2022-KR avgt 5 1076.745 ? 299.789 ns/op decodeCharsetName:?gc.alloc.rate.norm ISO-2022-KR avgt 5 808.068 ? 0.022 B/op Current: Benchmark (charsetName) Mode Cnt Score Error Units decodeCharsetName x-ISO-2022-CN-GB avgt 5 906.281 ? 109.035 ns/op decodeCharsetName:?gc.alloc.rate.norm x-ISO-2022-CN-GB avgt 5 920.077 ? 0.025 B/op decodeCharsetName ISO-2022-KR avgt 5 1175.228 ? 144.509 ns/op decodeCharsetName:?gc.alloc.rate.norm ISO-2022-KR avgt 5 1256.105 ? 0.043 B/op Patched: Benchmark (charsetName) Mode Cnt Score Error Units decodeCharsetName x-ISO-2022-CN-GB avgt 5 783.385 ? 255.048 ns/op decodeCharsetName:?gc.alloc.rate.norm x-ISO-2022-CN-GB avgt 5 584.050 ? 0.016 B/op decodeCharsetName ISO-2022-KR avgt 5 814.654 ? 196.860 ns/op decodeCharsetName:?gc.alloc.rate.norm ISO-2022-KR avgt 5 584.050 ? 0.024 B/op ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From redestad at openjdk.java.net Tue Feb 9 13:27:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 13:27:05 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets Message-ID: This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. Testing: tier1-3, manual runs of sun.nio.cs tests ------------- Commit messages: - Minor cleanup - Reduce decoder creation overheads for sun.nio.cs.ext Charsets Changes: https://git.openjdk.java.net/jdk/pull/2480/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261418 Stats: 761 lines in 15 files changed: 258 ins; 411 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/2480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2480/head:pull/2480 PR: https://git.openjdk.java.net/jdk/pull/2480 From sgehwolf at openjdk.java.net Tue Feb 9 13:31:25 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 9 Feb 2021 13:31:25 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4] In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. Severin Gehwolf 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 seven additional commits since the last revision: - Fix jcheck - Add documentation and reduce code running in the critical section - Add some documentation - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/0ece5f22..9a2d6a20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=02-03 Stats: 100580 lines in 2281 files changed: 44215 ins; 36687 del; 19678 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393 From sgehwolf at openjdk.java.net Tue Feb 9 13:45:39 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 9 Feb 2021 13:45:39 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Mon, 1 Feb 2021 20:26:54 GMT, Andrew John Hughes wrote: > > Anybody willing to review this? > > I can have a go. > > I have two main concerns: > > 1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too. The updated patch now includes some more documentation. The reason why I've removed some of it was because the logic changed and it was outdated. > 2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like: > if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } } I've changed this as suggested, but keep in mind no parsing of multiple files happens after this patch. It happens in CgroupSubsystemFactory. Thanks, Severin ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From github.com+471021+marschall at openjdk.java.net Tue Feb 9 14:10:41 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 9 Feb 2021 14:10:41 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3] In-Reply-To: <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com> References: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com> <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com> Message-ID: On Tue, 5 Jan 2021 18:10:52 GMT, Brian Burkhalter wrote: >> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright years > > src/java.base/share/classes/java/io/Reader.java line 198: > >> 196: } else { >> 197: int remaining = target.remaining(); >> 198: char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)]; > > As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help? That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is. We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From roger.riggs at oracle.com Tue Feb 9 14:32:02 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 9 Feb 2021 09:32:02 -0500 Subject: RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods In-Reply-To: References: Message-ID: Hi, It would be useful to drive a discussion of removing fallback provided by COMPACT_STRINGS? entirely. It was retained initially as a hedge against bugs in the new implementation. It adds complexity to the implementation and can hide implementation bugs. Regards, Roger On 2/9/21 7:50 AM, Aleksey Shipilev wrote: > Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. > > This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. > > The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. > > On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). > > Interpreter-only "Hello World": > > Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) > 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) > 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) > > Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): > > 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) > 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) > 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) > > 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) > > > OpenLiberty startup: > > Before: 2.296, 2.281, 2.291 (seconds) > After: 2.254, 2.267, 2.272 (seconds) > > Additional tests: > - [x] Linux `tier1` default (passes) > - [x] Linux `tier1` `-XX:-CompactStrings` > > ------------- > > Commit messages: > - Merge branch 'master' into JDK-8260710-string-inline > - Merge branch 'master' into JDK-8260710-string-inline > - Initial prototype > > Changes: https://git.openjdk.java.net/jdk/pull/2334/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2334&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8260710 > Stats: 173 lines in 5 files changed: 5 ins; 48 del; 120 mod > Patch: https://git.openjdk.java.net/jdk/pull/2334.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2334/head:pull/2334 > > PR: https://git.openjdk.java.net/jdk/pull/2334 From mbaesken at openjdk.java.net Tue Feb 9 15:08:46 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 15:08:46 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage Message-ID: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage ------------- Commit messages: - JDK-8261422 Changes: https://git.openjdk.java.net/jdk/pull/2483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261422 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2483/head:pull/2483 PR: https://git.openjdk.java.net/jdk/pull/2483 From mbaesken at openjdk.java.net Tue Feb 9 15:08:46 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 15:08:46 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage The method outOfBoundsMessage has a few problematic calls to String.format. Those calls use "%d" however the arguments are of type Number, so we should better use %s . Example : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM87A8sPJZZzON5wY&resolved=false&severities=BLOCKER&types=BUG return String.format("Index %d out of bounds for length %d", args.get(0), args.get(1)); Sonar error : An 'int' is expected rather than a . ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From sundar at openjdk.java.net Tue Feb 9 15:17:40 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 9 Feb 2021 15:17:40 GMT Subject: RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 16:09:01 GMT, Claes Redestad wrote: >> This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by: >> >> - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free >> - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists >> - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path) >> - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Copyrights and rename containsLocation LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2212 From github.com+471021+marschall at openjdk.java.net Tue Feb 9 15:31:09 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 9 Feb 2021 15:31:09 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5] In-Reply-To: References: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com> Message-ID: On Fri, 5 Feb 2021 22:08:17 GMT, Brian Burkhalter wrote: >> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: >> >> Limit amount read to avoid BufferOverflowException >> >> - limit the amount read >> - add tests > > src/java.base/share/classes/java/io/Reader.java line 194: > >> 192: nread = this.read(cbuf, off, len); >> 193: if (nread > 0) >> 194: target.position(target.position() + nread); > > As `target` is mutable, I think you would do better to change lines 189-194 to something like: > char cbuf[] = target.array(); > int pos = target.position(); > int rem = target.limit() - pos; > if (rem <= 0) > return -1; > int off = target.arrayOffset() + pos; > nread = this.read(cbuf, off, rem); > if (nread > 0) > target.position(pos + nread); Done ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Tue Feb 9 15:31:08 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 9 Feb 2021 15:31:08 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v6] In-Reply-To: References: Message-ID: > Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. Philippe Marschall has updated the pull request incrementally with four additional commits since the last revision: - Update copyright year - Implement review comment - Revert StreamDecoder changes - Implement CharArrayReader#read(CharBuffer) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1915/files - new: https://git.openjdk.java.net/jdk/pull/1915/files/a8531c1b..08948f93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=04-05 Stats: 105 lines in 3 files changed: 38 ins; 50 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915 From redestad at openjdk.java.net Tue Feb 9 15:35:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 15:35:40 GMT Subject: RFR: 8260337: Optimize ImageReader lookup, used by Class.getResource [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 18:22:54 GMT, Jim Laskey wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyrights and rename containsLocation > > Nice clean up. LGTM @JimLaskey @sundararajana - thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2212 From redestad at openjdk.java.net Tue Feb 9 15:35:43 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 15:35:43 GMT Subject: Integrated: 8260337: Optimize ImageReader lookup, used by Class.getResource In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 00:05:52 GMT, Claes Redestad wrote: > This patch optimizes the code paths exercised by `String.class.getResource("String.class")` by: > > - Adding an ASCII fast-path to methods verifying strings in the jimage, which can then be done allocation-free > - Avoiding the allocation of the `long[8]` attributes when verifying only for the purpose of verifying a path exists > - Using the `JNUA.create` fast-path in `SystemModuleReader` (which should be OK since we just verified the given name is a JRT path) > - Remove a redundant check in `Class::resolveName` and fitting the `StringBuilder` to size This pull request has now been integrated. Changeset: 2f893c2b Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/2f893c2b Stats: 393 lines in 8 files changed: 263 ins; 63 del; 67 mod 8260337: Optimize ImageReader lookup, used by Class.getResource Reviewed-by: jlaskey, sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/2212 From alanb at openjdk.java.net Tue Feb 9 15:36:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 9 Feb 2021 15:36:40 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v7] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:54:56 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > update src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 840: > 838: throw e; > 839: // Object could be a Unix domain socket > 840: try { Thanks for the updates, I think the fallback checking is correct everywhere now. What would you think about inverting the above so that it only checks for a socket file when followLinks && e.lastError() == ERROR_CANT_ACCESS_FILE. That would make it more consistent with the new code in WIndowsFileSystemProvider. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From alanb at openjdk.java.net Tue Feb 9 15:41:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 9 Feb 2021 15:41:39 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage src/java.base/share/classes/jdk/internal/util/Preconditions.java line 212: > 210: args.get(0), args.get(1), args.get(2)); > 211: case "checkFromIndexSize": > 212: return String.format("Range [%s, % References: Message-ID: On Thu, 4 Feb 2021 22:45:10 GMT, Ian Graves wrote: > A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559). This is an enhancement to update jlink's usage of `Collections.toList()` to `Stream.toList()`. This pull request has now been integrated. Changeset: edd5fc88 Author: Ian Graves Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/edd5fc88 Stats: 18 lines in 8 files changed: 0 ins; 5 del; 13 mod 8261096: Convert jlink tool to use Stream.toList() Reviewed-by: alanb, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/2416 From asemenyuk at openjdk.java.net Tue Feb 9 15:46:55 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 9 Feb 2021 15:46:55 GMT Subject: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources [v2] In-Reply-To: References: Message-ID: > Remove needless `#ifdef __cplusplus` from .cpp sources Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2466/files - new: https://git.openjdk.java.net/jdk/pull/2466/files/e9241319..bd1c3af5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2466&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2466&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2466/head:pull/2466 PR: https://git.openjdk.java.net/jdk/pull/2466 From asemenyuk at openjdk.java.net Tue Feb 9 15:46:56 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 9 Feb 2021 15:46:56 GMT Subject: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 04:03:14 GMT, Ioi Lam wrote: > The Bug Synopsis of 'Consider rewriting in C++ or moving to ".c" files' is unclear. > I would request that the Bug Synopsis to be changed to "removed unnecessary #ifdef __cplusplus" before integrating this PR. Bug Synopsis updated as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From mbaesken at openjdk.java.net Tue Feb 9 15:50:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 9 Feb 2021 15:50:39 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 15:38:29 GMT, Alan Bateman wrote: >> JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage > > src/java.base/share/classes/jdk/internal/util/Preconditions.java line 212: > >> 210: args.get(0), args.get(1), args.get(2)); >> 211: case "checkFromIndexSize": >> 212: return String.format("Range [%s, % > I assume we have a code coverage here and that we need tests to exercise these code paths. I haven't written the class Preconditions.java, this question should probably go to the authors . I found the String.format syntax a bit unusual, should this be rewritten ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From herrick at openjdk.java.net Tue Feb 9 16:01:43 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 9 Feb 2021 16:01:43 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 09:05:23 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports a new warning after JDK-8254702: > "Use of memory after it is freed" > > char* getJvmLauncherLibPath(void) { > ... > popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, > &launcherLibPath); > if (popenStatus) { > free(launcherLibPath); <---- frees here > goto cleanup; > } > } > > cleanup: > free(modulePath); > freePackageDesc(pkg); > > return launcherLibPath; <--- here > } > > We need to null it out before returning. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From iklam at openjdk.java.net Tue Feb 9 16:03:39 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 16:03:39 GMT Subject: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 15:46:55 GMT, Alexey Semenyuk wrote: >> Remove needless `#ifdef __cplusplus` from .cpp sources > > Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From github.com+18482851+stefan-zobel at openjdk.java.net Tue Feb 9 16:06:40 2021 From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel) Date: Tue, 9 Feb 2021 16:06:40 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 15:47:39 GMT, Matthias Baesken wrote: >> src/java.base/share/classes/jdk/internal/util/Preconditions.java line 212: >> >>> 210: args.get(0), args.get(1), args.get(2)); >>> 211: case "checkFromIndexSize": >>> 212: return String.format("Range [%s, %> >> I assume we have a code coverage here and that we need tests to exercise these code paths. > > I haven't written the class Preconditions.java, this question should probably go to the authors . > I found the String.format syntax a bit unusual, should this be rewritten ? AFAIK, Preconditions was introduced in https://bugs.openjdk.java.net/browse/JDK-8155794 ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From attila at openjdk.java.net Tue Feb 9 16:13:38 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Tue, 9 Feb 2021 16:13:38 GMT Subject: RFR: 8198540: Dynalink leaks memory when generating type converters [v7] In-Reply-To: References: <4xzM-PeZchhV65P2V2KHn2bmwEWd3HzLOSJLSe4nt2Q=.419fc509-471c-454b-be94-b9c103761103@github.com> Message-ID: On Tue, 9 Feb 2021 10:57:05 GMT, Hannes Walln?fer wrote: >> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename ClassLoaderRelation to RetentionDirection; it is better self-documenting this way. > > Nice work as ever, Attila. Looks good to me. Thanks for the review, Hannes! I must credit Peter too with how the final version of the code ended up, he really helped a lot with insightful comments and advice. ------------- PR: https://git.openjdk.java.net/jdk/pull/1918 From attila at openjdk.java.net Tue Feb 9 16:13:38 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Tue, 9 Feb 2021 16:13:38 GMT Subject: Integrated: 8198540: Dynalink leaks memory when generating type converters In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi wrote: > _(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading environments such as OSGi.)_ > > I'll explain this one in a bit more detail. Dynalink creates and caches method handles for language-specific conversions between types. Each conversion is thus characterized by a `Class` object representing the type converted from, and a `Class` object representing the type converted to, thus they're keyed by a pair of `(Class, Class)`. Java API provides the excellent `ClassValue` class for associating values with a single class, but it lacks the ? admittedly more niche ? facility for associating a value with a pair of classes. I originally solved this problem using something that looks like a `ClassValue, T>>`. I say "looks like" because Dynalink has a specialized `ClassMap` class that works like `Map, T>` but it also goes to some pains to _not_ establish strong references from a class loader to either its children or to unrelated class loaders, for obvious reasons. > > Surprisingly, the problem didn't lie in there, though. The problem was in the fact that `TypeConverterFactory` used `ClassValue` objects that were its non-static anonymous inner classes, and further the values they computed were also of non-static anonymous inner classes. Due to the way `ClassValue` internals work, this led to the `TypeConverterFactory` objects becoming anchored in a GC root of `Class.classValueMap` through the synthetic `this$0` reference chains in said inner classes? talk about non-obvious memory leaks. (I guess there's a lesson in there about not using `ClassValue` as an instance field, but there's a genuine need for them here, so?) > > ? so the first thing I did was I deconstructed all those anonymous inner classes into named static inner classes, and ended up with something that _did_ fix the memory leak (yay!) but at the same time there was a bunch of copying of constructor parameters from outer classes into the inner classes, the whole thing was very clunky with scary amounts of boilerplate. I felt there must exist a better solution. > > And it exists! I ended up replacing the `ClassValue>` construct with a ground-up implementation of `BiClassValue`, representation of lazily computed values associated with a pair of types. This was the right abstraction the `TypeConverterFactory` code needed all along. `BiClassValue` is also not implemented as an abstract class but rather it is a final class and takes a `BiFunction, Class, T>` for computation of its values, thus there's never a risk of making it an instance-specific inner class (well, you still need to be careful with the bifunction lambda?) It also has an even better solution for avoiding strong references to child class loaders. > > And that's why I'm not submitting here the smallest possible point fix to the memory leak, but rather a slightly larger one that architecturally fixes it the right way. > > There are two test classes, they test subtly different scenarios. `TypeConverterFactoryMemoryLeakTest` tests that when a `TypeConverterFactory` instance becomes unreachable, all method handles it created also become eligible for collection. `TypeConverterFactoryRetentionTests` on the other hand test that the factory itself won't prevent class loaders from being collected by virtue of creating converters for them. This pull request has now been integrated. Changeset: 8f4c15f6 Author: Attila Szegedi URL: https://git.openjdk.java.net/jdk/commit/8f4c15f6 Stats: 772 lines in 5 files changed: 538 ins; 220 del; 14 mod 8198540: Dynalink leaks memory when generating type converters Reviewed-by: plevart, hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/1918 From kcr at openjdk.java.net Tue Feb 9 16:33:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Feb 2021 16:33:38 GMT Subject: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources @alexeysemenyukoracle FYI, there was no need to force-push (or even push at all) to your branch. It doesn't matter at all what the commit message(s) of the commit(s) in the source branch are. Skara will use the title of the PR, which needs to match the JBS bug, as the final commit message. ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From bpb at openjdk.java.net Tue Feb 9 16:46:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 9 Feb 2021 16:46:39 GMT Subject: Integrated: 8261306: ServiceLoader documentation has malformed Unicode escape In-Reply-To: References: Message-ID: <4CMTZPnCy95HTddO32iruF8UZm8b7vHjpc5QYK_L-oo=.8e1be69a-dd87-41d5-b959-a25fc55f7571@github.com> On Tue, 9 Feb 2021 00:11:52 GMT, Brian Burkhalter wrote: > Please review this really small correction to the class level documentation of `java.util.ServiceLoader`. This pull request has now been integrated. Changeset: f395ee0c Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/f395ee0c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8261306: ServiceLoader documentation has malformed Unicode escape Reviewed-by: lancea, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2468 From iklam at openjdk.java.net Tue Feb 9 16:49:38 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 16:49:38 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 9 Feb 2021 09:20:45 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings >> >> STDERR: >> java.lang.OutOfMemoryError: Required length exceeds implementation limit >> at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) >> at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) >> at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) >> at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) >> at HugeCapacity.testLatin1(HugeCapacity.java:49) >> at HugeCapacity.main(HugeCapacity.java:37) >> >> I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. >> >> Additional testing: >> - [x] Linux x86_64, affected test (default), passes >> - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes >> - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes > > Anyone? :) Having two `@test` blocks makes the maintenance more difficult. I had to do a diff to find out the difference between the two blocks. There's an existing test that explicitly tests both `-XX:+CompactStrings` and `-XX:-CompactStrings`. Maybe we can do the same thing? https://github.com/openjdk/jdk/blob/8f4c15f6417e471b372f74460fa94b9d84c4811d/test/hotspot/jtreg/runtime/CompactStrings/TestMethodNames.java#L29 * @run main/othervm -Xms5G -Xmx5G -XX:+CompactStrings HugeCapacity true * @run main/othervm -Xms5G -Xmx5G -XX:-CompactStrings HugeCapacity false ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From asemenyuk at openjdk.java.net Tue Feb 9 16:56:36 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 9 Feb 2021 16:56:36 GMT Subject: RFR: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources > @alexeysemenyukoracle FYI, there was no need to force-push (or even push at all) to your branch. It doesn't matter at all what the commit message(s) of the commit(s) in the source branch are. Skara will use the title of the PR, which needs to match the JBS bug, as the final commit message. Thank you! I was wondering how it picks up a message for squashed commit that goes in open jdk repo. Now I know. ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From naoto at openjdk.java.net Tue Feb 9 17:12:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 17:12:40 GMT Subject: Integrated: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out In-Reply-To: References: Message-ID: <31EQg4pClcfWArGzgA-plSQB8un0d5J9lDTurXK2cPs=.e6a3461b-8773-43ac-8456-014e96b8a5d4@github.com> On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote: > Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out. This pull request has now been integrated. Changeset: becee643 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/becee643 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out Reviewed-by: bpb, lancea, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/2465 From iklam at openjdk.java.net Tue Feb 9 17:14:38 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 17:14:38 GMT Subject: RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 13:06:36 GMT, Claes Redestad wrote: >> Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`. >> >> This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly. >> >> The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers. >> >> On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles). >> >> Interpreter-only "Hello World": >> >> Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): >> >> 23.40 msec task-clock # 0.933 CPUs utilized ( +- 0.01% ) >> 86,133,190 cycles # 3.680 GHz ( +- 0.01% ) >> 79,854,588 instructions # 0.93 insn per cycle ( +- 0.00% ) >> >> 0.02507105 +- 0.00000343 seconds time elapsed ( +- 0.01% ) >> >> Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs): >> >> 23.07 msec task-clock # 0.935 CPUs utilized ( +- 0.01% ) >> 84,877,118 cycles # 3.679 GHz ( +- 0.01% ) >> 79,231,598 instructions # 0.93 insn per cycle ( +- 0.00% ) >> >> 0.02466467 +- 0.00000382 seconds time elapsed ( +- 0.02% ) >> >> >> OpenLiberty startup: >> >> Before: 2.296, 2.281, 2.291 (seconds) >> After: 2.254, 2.267, 2.272 (seconds) >> >> Additional tests: >> - [x] Linux `tier1` default (passes) >> - [x] Linux `tier1` `-XX:-CompactStrings` > > Looks good to me. > It would be useful to drive a discussion of removing fallback provided > by COMPACT_STRINGS? entirely. > It was retained initially as a hedge against bugs in the new implementation. > It adds complexity to the implementation and can hide implementation bugs. Isn't COMPACT_STRING inherently slower if you are processing predominantly Chinese/Japanese/Korean text? ------------- PR: https://git.openjdk.java.net/jdk/pull/2334 From shade at openjdk.java.net Tue Feb 9 17:49:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 17:49:39 GMT Subject: RFR: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 15:58:36 GMT, Andy Herrick wrote: >> SonarCloud instance reports a new warning after JDK-8254702: >> "Use of memory after it is freed" >> >> char* getJvmLauncherLibPath(void) { >> ... >> popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, >> &launcherLibPath); >> if (popenStatus) { >> free(launcherLibPath); <---- frees here >> goto cleanup; >> } >> } >> >> cleanup: >> free(modulePath); >> freePackageDesc(pkg); >> >> return launcherLibPath; <--- here >> } >> >> We need to null it out before returning. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) `tools/jpackage` > > Marked as reviewed by herrick (Reviewer). Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From shade at openjdk.java.net Tue Feb 9 17:49:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 17:49:38 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 00:06:19 GMT, Alexander Matveev wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> More cleanup in tstrings.cpp > > Marked as reviewed by almatvee (Committer). I had to redo `tstrings.cpp` to fix Windows failure. Turns out there was a `break` that exited the fake loop. I streamlined that code. ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From shade at openjdk.java.net Tue Feb 9 17:49:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 17:49:40 GMT Subject: Integrated: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 09:05:23 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports a new warning after JDK-8254702: > "Use of memory after it is freed" > > char* getJvmLauncherLibPath(void) { > ... > popenStatus = popenCommand(pkgQueryCmd, pkg->name, findLauncherLib, > &launcherLibPath); > if (popenStatus) { > free(launcherLibPath); <---- frees here > goto cleanup; > } > } > > cleanup: > free(modulePath); > freePackageDesc(pkg); > > return launcherLibPath; <--- here > } > > We need to null it out before returning. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` This pull request has now been integrated. Changeset: 01d92808 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/01d92808 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath Reviewed-by: stuefe, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/2453 From naoto.sato at oracle.com Tue Feb 9 17:52:29 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 9 Feb 2021 09:52:29 -0800 Subject: JEP draft: Use UTF-8 as default Charset Message-ID: Hello, We are planning to implement the following JEP draft: https://openjdk.java.net/jeps/8187041 This is a long-standing issue that has been causing cross-platform default encoding problems. Now that UTF-8 has increasingly become the de-facto character set out there, we believe it is high time to make UTF-8 as the default charset in the JDK. More detailed description can be found in the above JEP draft, so please take a look at it, and let us know your thoughts. Thank you. Naoto From joehw at openjdk.java.net Tue Feb 9 17:53:38 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 9 Feb 2021 17:53:38 GMT Subject: Integrated: 8261209: isStandalone property: remove dependency on pretty-print In-Reply-To: References: Message-ID: On Sat, 6 Feb 2021 00:38:15 GMT, Joe Wang wrote: > A quick fix to remove isStandalone's dependency on pretty-print. This pull request has now been integrated. Changeset: 7c565f8b Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/7c565f8b Stats: 36 lines in 3 files changed: 18 ins; 2 del; 16 mod 8261209: isStandalone property: remove dependency on pretty-print Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2442 From shade at openjdk.java.net Tue Feb 9 17:58:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 17:58:42 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 9 Feb 2021 16:47:14 GMT, Ioi Lam wrote: > Having two `@test` blocks makes the maintenance more difficult. I had to do a diff to find out the difference between the two blocks. > > There's an existing test that explicitly tests both `-XX:+CompactStrings` and `-XX:-CompactStrings`. Maybe we can do the same thing? No, I don't think we can. In other tests, the conflict between `-XX:+CompactStrings` and `-XX:-CompactStrings` would select one of the modes, so both test configurations would degenerate into one config (run twice). In this test, however, the compact strings mode defines whether the affected subtest would pass or fail, because it pokes at the allocation limit. So, we have to sense the actual setting of `CompactStrings` here. As I said, the alternative would be sensing it programmatically via `WhiteBox`, at expense at single `@test` config, but with `WhiteBox` ceremony. ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From dfuchs at openjdk.java.net Tue Feb 9 19:02:43 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 9 Feb 2021 19:02:43 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Tue, 9 Feb 2021 06:42:26 GMT, Joe Darcy wrote: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Small typos... src/java.base/share/classes/java/lang/Object.java line 81: > 79: * This integer need not remain consistent from one execution of an > 80: * application to another execution of the same application. > 81: *
    • If two objects are equal according to the {@link equals(Object) equals} I believe that should be: `{@link #equals(Object) equals}` (same a few line below). src/java.base/share/classes/java/math/BigDecimal.java line 81: > 79: * modes of operation of the arithmetic defined in ANSI X3.274-1996 > 80: * and ANSI X3.274-1996/AM 1-2000 (section 7.4). Unlike those > 81: * standards, {@code BigDecimal} includes many rounding modes Missing period at the end of the sentence (after "rounding modes")? src/java.base/share/classes/java/math/BigDecimal.java line 91: > 89: * used in the result's representation. > 90: > 91: * The different representations of same numerical value are called Should that be: The different representations of *a* same numerical value are called ... - or maybe value is missing a 's'? ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From naoto at openjdk.java.net Tue Feb 9 19:24:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 19:24:40 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad wrote: > This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) > > Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. > > Testing: tier1-3, manual runs of sun.nio.cs tests Thanks, Claes, for making the performance improvement. I have a few comments/questions. src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116: > 114: int sp = src.arrayOffset() + src.position(); > 115: int sl = src.arrayOffset() + src.limit(); > 116: I see these are removed from encode/decodeArrayLoop(s). Any reason behind those? src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64: > 62: > 63: protected final byte maximumDesignatorLength = 4; > 64: This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class? src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022_CN.java line 88: > 86: private byte currentSODesig; > 87: > 88: private static final DoubleByte.Decoder gb2312Decoder = Since this is a shared constant, I'd use all caps field name. ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From iklam at openjdk.java.net Tue Feb 9 19:31:36 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 19:31:36 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 9 Feb 2021 17:56:15 GMT, Aleksey Shipilev wrote: > > There's an existing test that explicitly tests both `-XX:+CompactStrings` and `-XX:-CompactStrings`. Maybe we can do the same thing? > > No, I don't think we can. In other tests, the conflict between `-XX:+CompactStrings` and `-XX:-CompactStrings` would select one of the modes, so both test configurations would degenerate into one config (run twice). I tried running `jtreg -vmoptions:-XX:+CompactStrings TestMethodNames.java` and the log file shows: (the first @test) -XX:+CompactStrings \ -XX:+CompactStrings \ com.sun.javatest.regtest.agent.MainWrapper /jdk2/tmp/jtreg/work/runtime/CompactStrings/TestMethodNames.d/main.0.jta (the second @test) -XX:+CompactStrings \ -XX:-CompactStrings \ com.sun.javatest.regtest.agent.MainWrapper /jdk2/tmp/jtreg/work/runtime/CompactStrings/TestMethodNames.d/main.1.jta The VM options specified by the `@test` line are appended after the options specified by `-vmoptions`. So this test is executed in two different configurations (not twice in the same configuration). ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From redestad at openjdk.java.net Tue Feb 9 19:45:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 19:45:42 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 19:14:09 GMT, Naoto Sato wrote: >> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) >> >> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. >> >> Testing: tier1-3, manual runs of sun.nio.cs tests > > src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116: > >> 114: int sp = src.arrayOffset() + src.position(); >> 115: int sl = src.arrayOffset() + src.limit(); >> 116: > > I see these are removed from encode/decodeArrayLoop(s). Any reason behind those? My IDE was marking the next line as redundant since `sp <= sl` will always be true. `buffer.position() <= buffer.limit()` is an invariant that I don't think we need to assert against here, and I think it's just been copy-pasted around mindlessly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From shade at openjdk.java.net Tue Feb 9 19:48:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 19:48:07 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings [v2] In-Reply-To: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings > > STDERR: > java.lang.OutOfMemoryError: Required length exceeds implementation limit > at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) > at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) > at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) > at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) > at HugeCapacity.testLatin1(HugeCapacity.java:49) > at HugeCapacity.main(HugeCapacity.java:37) > > I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. > > Additional testing: > - [x] Linux x86_64, affected test (default), passes > - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes > - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Remove non-essentials - Simplify - Merge branch 'master' into JDK-8260934-hugecapacity-cs - 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2355/files - new: https://git.openjdk.java.net/jdk/pull/2355/files/a4b0323c..856676d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2355&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2355&range=00-01 Stats: 28245 lines in 981 files changed: 16385 ins; 7685 del; 4175 mod Patch: https://git.openjdk.java.net/jdk/pull/2355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2355/head:pull/2355 PR: https://git.openjdk.java.net/jdk/pull/2355 From shade at openjdk.java.net Tue Feb 9 19:48:07 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 9 Feb 2021 19:48:07 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 9 Feb 2021 19:28:27 GMT, Ioi Lam wrote: > The VM options specified by the `@test` line are appended after the options specified by `-vmoptions`. So this test is executed in two different configurations (not twice in the same configuration). Right, okay, so the last option wins, this is good. We can do what the updated version does. ...but then we also need to handle platforms where `-XX:-CompactStrings` is set by platform config (e.g. on ARM). `-XX:+CompactStrings` would be ignored there, and we cannot run test with `true` then. I think only ARM32 is affected, so it would be filtered by existing `@requires`, so it can be resolved later. ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From naoto at openjdk.java.net Tue Feb 9 19:52:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 19:52:40 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 19:43:06 GMT, Claes Redestad wrote: >> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116: >> >>> 114: int sp = src.arrayOffset() + src.position(); >>> 115: int sl = src.arrayOffset() + src.limit(); >>> 116: >> >> I see these are removed from encode/decodeArrayLoop(s). Any reason behind those? > > My IDE was marking the next line as redundant since `sp <= sl` will always be true. `buffer.position() <= buffer.limit()` is an invariant that I don't think we need to assert against here, and I think it's just been copy-pasted around mindlessly. Thanks, got it. I was wondering any possibility of sp > sl case. ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From iklam at openjdk.java.net Tue Feb 9 20:00:42 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 9 Feb 2021 20:00:42 GMT Subject: RFR: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings [v2] In-Reply-To: References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 9 Feb 2021 19:48:07 GMT, Aleksey Shipilev wrote: >> $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings >> >> STDERR: >> java.lang.OutOfMemoryError: Required length exceeds implementation limit >> at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) >> at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) >> at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) >> at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) >> at HugeCapacity.testLatin1(HugeCapacity.java:49) >> at HugeCapacity.main(HugeCapacity.java:37) >> >> I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. >> >> Additional testing: >> - [x] Linux x86_64, affected test (default), passes >> - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes >> - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove non-essentials > - Simplify > - Merge branch 'master' into JDK-8260934-hugecapacity-cs > - 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From darcy at openjdk.java.net Tue Feb 9 20:22:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 9 Feb 2021 20:22:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Tue, 9 Feb 2021 18:51:33 GMT, Daniel Fuchs wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > src/java.base/share/classes/java/lang/Object.java line 81: > >> 79: * This integer need not remain consistent from one execution of an >> 80: * application to another execution of the same application. >> 81: *
    • If two objects are equal according to the {@link equals(Object) equals} > > I believe that should be: `{@link #equals(Object) equals}` (same a few line below). The `{@link equals(Object) equals}` idiom does result in the desired link in the generated javadoc. > src/java.base/share/classes/java/math/BigDecimal.java line 81: > >> 79: * modes of operation of the arithmetic defined in ANSI X3.274-1996 >> 80: * and ANSI X3.274-1996/AM 1-2000 (section 7.4). Unlike those >> 81: * standards, {@code BigDecimal} includes many rounding modes > > Missing period at the end of the sentence (after "rounding modes")? Quite right; will fix in the next push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Tue Feb 9 20:27:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 9 Feb 2021 20:27:52 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v2] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typos found in code review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/e6fde07a..f0d4d2b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Tue Feb 9 20:27:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 9 Feb 2021 20:27:53 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v2] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: <5LyoOGHawVZsQ7_LUFPBxR0NJpEw7EwqPeX2dKZE1hU=.81d112e8-0b68-4837-a7cb-8002683b5516@github.com> On Tue, 9 Feb 2021 18:55:52 GMT, Daniel Fuchs wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos found in code review. > > src/java.base/share/classes/java/math/BigDecimal.java line 91: > >> 89: * used in the result's representation. >> 90: >> 91: * The different representations of same numerical value are called > > Should that be: > The different representations of *a* same numerical value are called ... - or maybe value is missing a 's'? Missing "the" -- will fix; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From redestad at openjdk.java.net Tue Feb 9 21:05:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 21:05:41 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 19:19:18 GMT, Naoto Sato wrote: >> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) >> >> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. >> >> Testing: tier1-3, manual runs of sun.nio.cs tests > > src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022_CN.java line 88: > >> 86: private byte currentSODesig; >> 87: >> 88: private static final DoubleByte.Decoder gb2312Decoder = > > Since this is a shared constant, I'd use all caps field name. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From redestad at openjdk.java.net Tue Feb 9 21:14:55 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 21:14:55 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v2] In-Reply-To: References: Message-ID: > This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) > > Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. > > Testing: tier1-3, manual runs of sun.nio.cs tests Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Review fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2480/files - new: https://git.openjdk.java.net/jdk/pull/2480/files/9ed39a90..aa24f031 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2480/head:pull/2480 PR: https://git.openjdk.java.net/jdk/pull/2480 From redestad at openjdk.java.net Tue Feb 9 21:14:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 9 Feb 2021 21:14:56 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 19:18:04 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fixes > > src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64: > >> 62: >> 63: protected final byte maximumDesignatorLength = 4; >> 64: > > This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class? The KR concrete impl is the only instantiation of this default impl - all other were already implementing specialized `Decoders` that does not inherit from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR class uses a `DoubleByte.Decoder` that can now be created statically and used directly in the `decode` method - bypassing the `tmpDecoder` indirection and using tiny array+buffers which added quite a bit of overhead. So the performance gain here was significant, and is the explanation `ISO2022_KR` is now significantly ahead of the baseline on the `StringDecode` micro. ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From naoto at openjdk.java.net Tue Feb 9 21:38:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 9 Feb 2021 21:38:41 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v2] In-Reply-To: References: Message-ID: <2GUT8vaOuE8qT3FnKWh36blfv_Vdgr3eiUt770NNRbU=.1cc4df4d-5729-4702-bd99-7f542633d473@github.com> On Tue, 9 Feb 2021 21:10:18 GMT, Claes Redestad wrote: >> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64: >> >>> 62: >>> 63: protected final byte maximumDesignatorLength = 4; >>> 64: >> >> This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class? > > The KR concrete impl is the only instantiation of this default impl - all other were already implementing specialized `Decoders` that does not inherit from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR class uses a `DoubleByte.Decoder` that can now be created statically and used directly in the `decode` method - bypassing the `tmpDecoder` indirection and using tiny array+buffers which added quite a bit of overhead. So the performance gain here was significant, and is the explanation `ISO2022_KR` is now significantly ahead of the baseline on the `StringDecode` micro. OK. I don't think any more new ISO2022 charset would be added, so personally I still prefer the default impl in the ISO2022 itself, but I am ok with the code, as it improves the performance. Would you please add a comment explaining it? ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From iignatyev at openjdk.java.net Tue Feb 9 22:18:45 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 9 Feb 2021 22:18:45 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v5] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 20:12:03 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - 8166026: Refactor java/lang shell tests to java > - 8166026: Refactor java/lang shell tests to java > - 8166026: Refactor java/lang shell tests to java > - 8166026: Refactor java/lang shell tests to java Changes requested by iignatyev (Reviewer). test/jdk/java/lang/annotation/LoaderLeakTest.java line 2: > 1: /* > 2: * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved. it's 2021 test/jdk/java/lang/annotation/LoaderLeakTest.java line 78: > 76: // URL classes = new URL("file://" + System.getProperty("user.dir") + "/classes"); > 77: // URL[] path = { classes }; > 78: // URLClassLoader loader = new URLClassLoader(path); please remove the commented out lines (L76-78) test/jdk/java/lang/annotation/LoaderLeakTest.java line 128: > 126: > 127: @Override > 128: public synchronized Class loadClass(String className, boolean resolveIt) does it need to be `synchronized` ? test/jdk/java/lang/annotation/LoaderLeakTest.java line 123: > 121: return Files.readAllBytes(Paths.get(className + ".class")); > 122: } catch (Exception e) { > 123: throw new Error(e); could you please use a descriptive message here (and include `className` value into it), so it will be easier to analyze test failures? test/jdk/java/lang/annotation/LoaderLeakTest.java line 119: > 117: > 118: private byte[] getClassImplFromDataBase(String className) { > 119: byte result[]; unused test/jdk/java/lang/annotation/LoaderLeakTest.java line 80: > 78: // URLClassLoader loader = new URLClassLoader(path); > 79: ClassLoader loader = new SimpleClassLoader(); > 80: WeakReference> c = new WeakReference>(loader.loadClass("C")); nit: I'd use `var` here. test/jdk/java/lang/annotation/LoaderLeakTest.java line 82: > 80: WeakReference> c = new WeakReference>(loader.loadClass("C")); > 81: if (c.get() == null) throw new AssertionError(); > 82: if (c.get().getClassLoader() != loader) throw new AssertionError(); please use the messages which explain what went wrong, so when the failure happens, the person who analyze it won't have to open test code every time to just understand which of assertions was hit. test/jdk/java/lang/annotation/LoaderLeakTest.java line 106: > 104: } > 105: > 106: @java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME) nit: I'd import these types from j.l.a ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From iignatyev at openjdk.java.net Tue Feb 9 22:18:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 9 Feb 2021 22:18:46 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 13:39:04 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/annotation/LoaderLeakTest.java line 64: > >> 62: @Test >> 63: public void testWithoutReadingAnnotations() throws Throwable { >> 64: runJavaProcessExpectSuccessExitCode("Main"); > > indentation here looks wierd indentation still looks weird here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From asemenyuk at openjdk.java.net Tue Feb 9 22:24:39 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 9 Feb 2021 22:24:39 GMT Subject: Integrated: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 22:26:22 GMT, Alexey Semenyuk wrote: > Remove needless `#ifdef __cplusplus` from .cpp sources This pull request has now been integrated. Changeset: 699a3cde Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/699a3cde Stats: 10 lines in 2 files changed: 0 ins; 6 del; 4 mod 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources Reviewed-by: herrick, almatvee, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/2466 From mik3hall at gmail.com Tue Feb 9 22:29:00 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 9 Feb 2021 16:29:00 -0600 Subject: Jpackage GraalVM OS X Message-ID: <306BA6BA-3B8D-49ED-803F-258ECC22CBA3@gmail.com> This appears to no longer work at all as a included JRE With? --runtime-image /Library/Java/JavaVirtualMachines/graalvm-ce-java11-21.0.0/Contents/Home \ It fails to launch. Launch CLI outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP Failed to find JVM in "/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/runtime" directory. Although it is in fact there? ls /Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/runtime/Contents Home Info.plist MacOS _CodeSignature I thought code signing might fix some other issues I had with this previously now that that is working. From asemenyuk at openjdk.java.net Tue Feb 9 22:29:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 9 Feb 2021 22:29:41 GMT Subject: RFR: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks [v3] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 08:58:23 GMT, Aleksey Shipilev wrote: >> After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." >> >> int initJvmlLauncherData(JvmlLauncherData* ptr) const { >> // Store path to JLI library just behind JvmlLauncherData header. >> char* curPtr = reinterpret_cast(ptr + 1); >> do { >> const size_t count = sizeof(char) >> * (jliLibPath.size() + 1 /* trailing zero */); >> if (ptr) { >> std::memcpy(curPtr, jliLibPath.c_str(), count); >> ptr->jliLibPath = curPtr; >> } >> curPtr += count; >> } while (false); // <---- here >> >> There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. >> >> Additional testing: >> - [x] Linux x86_64 (Ubuntu) tools/jpackage > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Fix Windows build failure: illegal break (where while loop used to be) > - Merge branch 'master' into JDK-8261300-jpackage-while-0 > - More cleanup in tstrings.cpp > - Replace with {} Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From bpb at openjdk.java.net Tue Feb 9 23:35:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 9 Feb 2021 23:35:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v2] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Tue, 9 Feb 2021 20:27:52 GMT, Joe Darcy wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos found in code review. src/java.base/share/classes/java/lang/Object.java line 148: > 146: * relation, each equivalence class only has a single element. > 147: * > 148: * @apiNoted `s/apiNoted/apiNote/` src/java.base/share/classes/java/lang/Object.java line 198: > 196: * need to be modified. > 197: * > 198: * @implspec `s/implspec/implSpec/` src/java.base/share/classes/java/math/BigDecimal.java line 3062: > 3060: > 3061: * @apiNote > 3062: * Note: this class has a natural ordering that is inconsistent with equals. Is `Note: ` really needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From dholmes at openjdk.java.net Wed Feb 10 01:42:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 10 Feb 2021 01:42:39 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader In-Reply-To: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: <7ttxRIBoaZSM04YoncG5q6mH9fkNYO5lksu3O3WNObc=.14617a81-82d2-4b30-80ae-6ec7ba9744dd@github.com> On Tue, 9 Feb 2021 15:40:03 GMT, Aleksey Shipilev wrote: > `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). > > The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. > > Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. > > On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` > `$ git checkout pull/2485` Hi Aleksey, This seems reasonable to me. The generated reflection classes are loaded by a temporary loader (so they can be unloaded) and so have to be skipped. I've added core-libs to the PR as this is the VM side of their code and I want to make sure nothing has been overlooked. Thanks, David src/hotspot/share/prims/jvm.cpp line 3293: > 3291: oop loader = ik->class_loader(); > 3292: if (loader != NULL && !SystemDictionary::is_platform_class_loader(loader)) { > 3293: if (!ik->is_subclass_of(vmClasses::reflect_MethodAccessorImpl_klass()) && Please add a comment: // Skip reflection related frames ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2485 From darcy at openjdk.java.net Wed Feb 10 01:49:55 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 10 Feb 2021 01:49:55 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typos in javadoc tags found during review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/f0d4d2b7..2a8dd8ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Wed Feb 10 01:58:40 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 10 Feb 2021 01:58:40 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Tue, 9 Feb 2021 19:41:25 GMT, Brian Burkhalter wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 148: > >> 146: * relation, each equivalence class only has a single element. >> 147: * >> 148: * @apiNoted > > `s/apiNoted/apiNote/` Fixed. I did run a successful docs builds before sending out the change for review and I'm surprised the unrecognized tags didn't trigger a docs build failure. thanks. > src/java.base/share/classes/java/math/BigDecimal.java line 3062: > >> 3060: >> 3061: * @apiNote >> 3062: * Note: this class has a natural ordering that is inconsistent with equals. > > Is `Note: ` really needed? This is the exact text recommended in java.lang.Comparable when a type's natural ordering is inconsistent with equals. The statement to that effect at the top of BigDecimal didn't use that exact wording ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From bpb at openjdk.java.net Wed Feb 10 02:58:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Feb 2021 02:58:38 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Wed, 10 Feb 2021 01:49:55 GMT, Joe Darcy wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos in javadoc tags found during review. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From bpb at openjdk.java.net Wed Feb 10 02:58:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Feb 2021 02:58:39 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Wed, 10 Feb 2021 01:55:24 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 3062: >> >>> 3060: >>> 3061: * @apiNote >>> 3062: * Note: this class has a natural ordering that is inconsistent with equals. >> >> Is `Note: ` really needed? > > This is the exact text recommended in java.lang.Comparable when a type's natural ordering is inconsistent with equals. The statement to that effect at the top of BigDecimal didn't use that exact wording Okay, I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From shade at openjdk.java.net Wed Feb 10 07:34:59 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Feb 2021 07:34:59 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: > `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). > > The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. > > Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. > > On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` > `$ git checkout pull/2485` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Added a comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2485/files - new: https://git.openjdk.java.net/jdk/pull/2485/files/fc333037..72e830a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2485&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2485&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485 PR: https://git.openjdk.java.net/jdk/pull/2485 From shade at openjdk.java.net Wed Feb 10 07:35:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Feb 2021 07:35:00 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: <7ttxRIBoaZSM04YoncG5q6mH9fkNYO5lksu3O3WNObc=.14617a81-82d2-4b30-80ae-6ec7ba9744dd@github.com> References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> <7ttxRIBoaZSM04YoncG5q6mH9fkNYO5lksu3O3WNObc=.14617a81-82d2-4b30-80ae-6ec7ba9744dd@github.com> Message-ID: On Wed, 10 Feb 2021 01:29:51 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment > > src/hotspot/share/prims/jvm.cpp line 3293: > >> 3291: oop loader = ik->class_loader(); >> 3292: if (loader != NULL && !SystemDictionary::is_platform_class_loader(loader)) { >> 3293: if (!ik->is_subclass_of(vmClasses::reflect_MethodAccessorImpl_klass()) && > > Please add a comment: > // Skip reflection related frames Added! ------------- PR: https://git.openjdk.java.net/jdk/pull/2485 From shade at openjdk.java.net Wed Feb 10 07:35:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Feb 2021 07:35:38 GMT Subject: Integrated: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings In-Reply-To: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> References: <6hpIrSAicA1Le3iUVF5KrkeL3a8vPG1kDt_ia5bB-wo=.f8c97667-2fda-453e-a402-23e573476a7d@github.com> Message-ID: On Tue, 2 Feb 2021 15:38:01 GMT, Aleksey Shipilev wrote: > $ CONF=linux-x86_64-server-fastdebug make run-test TEST=java/lang/StringBuilder/HugeCapacity.java TEST_VM_OPTS=-XX:-CompactStrings > > STDERR: > java.lang.OutOfMemoryError: Required length exceeds implementation limit > at java.base/java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:259) > at java.base/java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:229) > at java.base/java.lang.AbstractStringBuilder.ensureCapacity(AbstractStringBuilder.java:213) > at java.base/java.lang.StringBuilder.ensureCapacity(StringBuilder.java:87) > at HugeCapacity.testLatin1(HugeCapacity.java:49) > at HugeCapacity.main(HugeCapacity.java:37) > > I went back and forth in fixing this test, and I think the best we can do is sense the current setting on `CompactStrings` and choose the test configuration based on that. The alternative is to use `WhiteBox` within the test (tried, it is quite a bit ugly). Note that this test deliberately does not run `-XX:-CompactStrings` even when `vm.opt.final.CompactStrings` returns true (= "available"), because that might mean `TEST_VM_OPTS=-XX:+CompactStrings` is in effect, and we have the VM option conflict. > > Additional testing: > - [x] Linux x86_64, affected test (default), passes > - [x] Linux x86_64, affected test (`-XX:-CompactStrings`), passes > - [x] Linux x86_64, affected test (`-XX:+CompactStrings`), passes This pull request has now been integrated. Changeset: ad54d8dd Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ad54d8dd Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/2355 From shade at openjdk.java.net Wed Feb 10 07:38:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Feb 2021 07:38:36 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: References: <6BCJ2YSNkCvyNezMKtpkWmXFuO1Pxxvm0JacqXy1l0o=.0e06a2b8-d833-4e83-9fb9-cc8924d663df@github.com> Message-ID: On Tue, 9 Feb 2021 08:56:22 GMT, Aleksey Shipilev wrote: >> Marked as reviewed by almatvee (Committer). > > Ah. Still looking for formal Reviewer to ack. Still need formal Reviewer, preferably from jpackage. @andyherrick? ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From michaelm at openjdk.java.net Wed Feb 10 07:46:02 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 10 Feb 2021 07:46:02 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v8] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon 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 16 additional commits since the last revision: - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files - Merge branch 'master' into 8252971-socket-attributes - update - fix mistake in last push - update - Merge branch 'master' into 8252971-socket-attributes - add specific check for unix domain socket - Merge branch 'master' into 8252971-socket-attributes - update - update - ... and 6 more: https://git.openjdk.java.net/jdk/compare/a7819067...70832057 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/92031fbc..70832057 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=06-07 Stats: 9487 lines in 220 files changed: 5561 ins; 2694 del; 1232 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Wed Feb 10 07:46:03 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 10 Feb 2021 07:46:03 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v7] In-Reply-To: References: Message-ID: <0ILafV5KyqKOSm1xGyM5BU2rG3elgqHN6g94_uTIBhI=.ea4583af-588b-4534-b513-4f0f069c6cb2@github.com> On Tue, 9 Feb 2021 15:33:48 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 840: > >> 838: throw e; >> 839: // Object could be a Unix domain socket >> 840: try { > > Thanks for the updates, I think the fallback checking is correct everywhere now. > What would you think about inverting the above so that it only checks for a socket file when followLinks && e.lastError() == ERROR_CANT_ACCESS_FILE. That would make it more consistent with the new code in WIndowsFileSystemProvider. Okay. No problem. The next revision also includes an updated test where I found some socket files weren't being cleaned up at the end of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From sgehwolf at openjdk.java.net Wed Feb 10 08:52:36 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 10 Feb 2021 08:52:36 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Mon, 1 Feb 2021 20:26:54 GMT, Andrew John Hughes wrote: >> Anybody willing to review this? > >> Anybody willing to review this? > > I can have a go. > > I have two main concerns: > > 1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too. > 2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like: > if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } } @gnu-andrew Let me know what you think of the updated patch! Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From dfuchs at openjdk.java.net Wed Feb 10 11:12:45 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Feb 2021 11:12:45 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v8] In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 07:46:02 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > Michael McMahon 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 16 additional commits since the last revision: > > - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files > - Merge branch 'master' into 8252971-socket-attributes > - update > - fix mistake in last push > - update > - Merge branch 'master' into 8252971-socket-attributes > - add specific check for unix domain socket > - Merge branch 'master' into 8252971-socket-attributes > - update > - update > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/f61a6ff5...70832057 Changes LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From github.com+7693005+jarviscraft at openjdk.java.net Wed Feb 10 14:10:39 2021 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Wed, 10 Feb 2021 14:10:39 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Thu, 7 Jan 2021 17:09:14 GMT, Claes Redestad wrote: >> Hi Claes, >> Would flattening the state of MD5 bring any further improvements? >> https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083 > >> Hi Claes, >> Would flattening the state of MD5 bring any further improvements? >> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) > > I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > > > @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From herrick at openjdk.java.net Wed Feb 10 14:12:37 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 10 Feb 2021 14:12:37 GMT Subject: RFR: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 08:49:17 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports as new warning after JDK-8254702: > > This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. > > char* getJvmLauncherLibPath(void) { > ... > if (PACKAGE_TYPE_RPM == pkg->type) { > pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; > } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here > pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; > > Seems like an obvious typo. > > Additional tests: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From redestad at openjdk.java.net Wed Feb 10 14:47:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 10 Feb 2021 14:47:39 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! FWIW, I ended up doing two related improvements: - #1855 - which reduced overheads of constructing MD5, SHA1, SHA2, SHA5 `MessageDigest` objects, and slightly improving digest performance - #1933 - reducing cost of `MessageDigest.getInstance` in general by better internal caching of `Constructor` objects, among other things. With this there's now no extra allocations when looking up something that has been looked up before. Together these enhancements bring the overheads of `UUID.nameUUIDFromBytes` down close to what you can get from cloning from a `ThreadLocal` `MD5` object as suggested here. Taking the ambient overheads of `ThreadLocal`s into account I'd say it's not worth adding this cache, and would suggest withdrawing this PR and closing the RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From shade at openjdk.java.net Wed Feb 10 15:11:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Feb 2021 15:11:40 GMT Subject: Integrated: 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo In-Reply-To: References: Message-ID: <9PrY0IpWRRiJIDGAWW-C2muBSLhKzgholSEVmBZ9Idk=.6606e2b1-baec-4e0e-a0dc-0e29014479d4@github.com> On Mon, 8 Feb 2021 08:49:17 GMT, Aleksey Shipilev wrote: > SonarCloud instance reports as new warning after JDK-8254702: > > This branch can not be reached because the condition duplicates a previous condition in the same sequence of "if/else if" statements. > > char* getJvmLauncherLibPath(void) { > ... > if (PACKAGE_TYPE_RPM == pkg->type) { > pkgQueryCmd = "rpm -ql '%s' 2>/dev/null"; > } else if (PACKAGE_TYPE_RPM == pkg->type) { <--- here > pkgQueryCmd = "dpkg -L '%s' 2>/dev/null"; > > Seems like an obvious typo. > > Additional tests: > - [x] Linux x86_64 (Ubuntu) `tools/jpackage` This pull request has now been integrated. Changeset: a7726390 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a7726390 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8261298: LinuxPackage.c, getJvmLauncherLibPath RPM->DEB typo Reviewed-by: asemenyuk, almatvee, herrick ------------- PR: https://git.openjdk.java.net/jdk/pull/2452 From stuefe at openjdk.java.net Wed Feb 10 15:29:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 10 Feb 2021 15:29:40 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: On Wed, 10 Feb 2021 07:34:59 GMT, Aleksey Shipilev wrote: >> `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). >> >> The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. >> >> Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. >> >> On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. >> >> Additional testing: >> - [x] Ad-hoc benchmarks >> - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` >> `$ git checkout pull/2485` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment Looks good. I find it simpler too. You could run the tests with sun.reflect.inflationThreshold=0. Should increase the chance of encountering reflection delegator loaders a lot. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2485 From chegar at openjdk.java.net Wed Feb 10 15:53:54 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 10 Feb 2021 15:53:54 GMT Subject: RFR: 8261160: Add a deserialization JFR event Message-ID: This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. ------------- Commit messages: - minor cleanup; all tests passing - Unconditionally fire a deser event regardless of filter, and add test - commit 2 - commit 1 Changes: https://git.openjdk.java.net/jdk/pull/2479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261160 Stats: 516 lines in 12 files changed: 496 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Wed Feb 10 16:09:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 10 Feb 2021 16:09:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. The logging in ObjectInputStream remains conditional on whether a filter is installed, which that seems reasonable since the logging is filter specific, while the JRF event is not (but both carry effectively the same information). The new jdk.Deserialization event uses a String to carry the filterStatus value. The value could be represented by its enum ordinal, but then the tool consuming the event would need to map that back to its string value to be meaningful. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From coffeys at openjdk.java.net Wed Feb 10 16:16:40 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 10 Feb 2021 16:16:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Marked as reviewed by coffeys (Reviewer). test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java line 50: > 48: * -Dexpected-jdk.serialFilter=java.** GlobalFilterTest > 49: * @run testng/othervm/policy=security.policy GlobalFilterTest > 50: * @run testng/othervm/policy=security.policy You may want to add a "@requires vm.hasJFR" condition to this test ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From rriggs at openjdk.java.net Wed Feb 10 20:32:43 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 10 Feb 2021 20:32:43 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Wed Feb 10 21:00:41 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Feb 2021 21:00:41 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 35: > 33: > 34: @Category({"Java Development Kit", "Serialization"}) > 35: @Label("Deserialization events") This seems to differ from the format of other event labels defined in this package, e.g: @Label("Process Start") @Label("File Read") ... What would you think of changing it to one of: @Label("Deserialization") @Label("Deserialized Object") ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From bpb at openjdk.java.net Wed Feb 10 22:00:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Feb 2021 22:00:39 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3] In-Reply-To: References: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com> <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com> Message-ID: <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com> On Tue, 9 Feb 2021 14:08:10 GMT, Philippe Marschall wrote: >> src/java.base/share/classes/java/io/Reader.java line 198: >> >>> 196: } else { >>> 197: int remaining = target.remaining(); >>> 198: char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)]; >> >> As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help? > > That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is. > > We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip. Perhaps a static final `WORK_BUFFER_SIZE` could be added with value 8192 and `maxSkipBufferSize` and `TRANSFER_BUFFER_SIZE` replaced with that? Then `skipBuffer` could be renamed to `workBuffer` and used in both `read(CharBuffer)` and `skip(long)`. That shouldn't be a problem as both uses are in synchronized blocks. Also I suggest putting the declaration of `workBuffer` just below that of `lock` instead of lower down the file where `skipBuffer` is. Lastly you mentioned C-style array declarations like `char buf[]`. As there are only four of these in the file it might be good to just go ahead and change them, I don't think that adds much noise or risk. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From redestad at openjdk.java.net Wed Feb 10 23:35:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 10 Feb 2021 23:35:54 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v3] In-Reply-To: References: Message-ID: > This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) > > Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. > > Testing: tier1-3, manual runs of sun.nio.cs tests Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add comment about removing the generic ISO2022.Decoder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2480/files - new: https://git.openjdk.java.net/jdk/pull/2480/files/aa24f031..fa593915 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=01-02 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2480.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2480/head:pull/2480 PR: https://git.openjdk.java.net/jdk/pull/2480 From naoto at openjdk.java.net Wed Feb 10 23:41:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 10 Feb 2021 23:41:41 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v3] In-Reply-To: References: Message-ID: On Wed, 10 Feb 2021 23:35:54 GMT, Claes Redestad wrote: >> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) >> >> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. >> >> Testing: tier1-3, manual runs of sun.nio.cs tests > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about removing the generic ISO2022.Decoder Thanks. The newly added comment to ISO2022 is helpful. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2480 From lzang at openjdk.java.net Thu Feb 11 02:40:47 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 11 Feb 2021 02:40:47 GMT Subject: RFR: 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially Message-ID: 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially ------------- Commit messages: - 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially Changes: https://git.openjdk.java.net/jdk/pull/2519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261482 Stats: 50 lines in 4 files changed: 7 ins; 22 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2519/head:pull/2519 PR: https://git.openjdk.java.net/jdk/pull/2519 From lzang at openjdk.java.net Thu Feb 11 02:46:38 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 11 Feb 2021 02:46:38 GMT Subject: RFR: 8261482: Adjust jmap histo command to accept noparallel option to inspect heap serially In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 02:36:01 GMT, Lin Zang wrote: > 8261482: Adjust jmap histo command to accept noparallel option to inspect heap serially Dear All, Stories and discussions related with this PR could be found at #2379 and #2261. Just FYI. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2519 From smarks at openjdk.java.net Thu Feb 11 04:49:41 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 11 Feb 2021 04:49:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Wed, 10 Feb 2021 01:49:55 GMT, Joe Darcy wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos in javadoc tags found during review. Overall very nice. Mostly my comments are wordsmithing. Two issues are worth considering; see detailed comments inline. 1) Do we want a general statement on the stability of the value returned by toString()? 2) Add rationale and example for why BigDecimal's natural ordering is inconsistent with equals. src/java.base/share/classes/java/lang/Comparable.java line 68: > 66: * orderings that are consistent with equals. One exception is > 67: * {@link java.math.BigDecimal}, whose {@linkplain java.math.BigDecimal#compareTo natural ordering} equates > 68: * {@code BigDecimal} objects with equal numerical values and different representations Nothing here talks about the representation of BigDecimal. I think it would be preferable to say that in BigDecimal, the `equals()` method considers 4.0 and 4.00 unequal because they have different precisions; however, `compareTo()` considers them equal because it considers only their numerical values. src/java.base/share/classes/java/lang/Comparable.java line 90: > 88: * of the {@code equals} method and the equivalence classes defined by > 89: * the quotient of the {@code compareTo} method are the same. > 90: * I think in both cases it should be "the equivalence class defined by...." That is, "equivalence class" should be singular. But there are two of them, so the sentence still properly concludes "... are the same." src/java.base/share/classes/java/lang/Comparable.java line 110: > 108: * {@link Integer#signum signum}{@code (x.compareTo(y)) == -signum(y.compareTo(x))} > 109: * for all {@code x} and {@code y}. (This > 110: * implies that {@code x.compareTo(y)} must throw an exception iff I'd suggest replacing "iff" with "if and only if" because it looks like a typo, and writing out the long form emphasizes the bidirectional nature of the implication. src/java.base/share/classes/java/lang/Object.java line 135: > 133: * into equivalence classes; all the members of an > 134: * equivalence class are equal to each other. The equal objects > 135: * are substitutable for each other, at least for some purposes. Since the preceding sentence mentions the members of an equivalence class, it might read better to say "Members are substitutable..." or possibly "Members of an equivalence class are substitutable...." src/java.base/share/classes/java/lang/Object.java line 149: > 147: * > 148: * @apiNote > 149: * Note that it is generally necessary to override the {@link hashCode hashCode} The `@apiNote` introduces the paragraph with a subhead "API Note:" so it's a bit redundant to say "Note that...." Maybe just start with "It is generally necessary...." src/java.base/share/classes/java/lang/Object.java line 236: > 234: * be a concise but informative representation that is easy for a > 235: * person to read. > 236: * It is recommended that all subclasses override this method. Do we want to have a general note here or somewhere that the exact format of the result of `toString()` is generally not stable, and that it is subject to change without notice? src/java.base/share/classes/java/math/BigDecimal.java line 97: > 95: * contrast, the {@link equals equals} method requires both the > 96: * numerical value and representation to be the same for equality to > 97: * hold. Note, discussing "representation" is ok here since the context is discussing the representation of BigDecimal (in contrast to the text in Comparable). src/java.base/share/classes/java/util/Comparator.java line 95: > 93: * equals, the equivalence classes defined by the equivalence relation > 94: * of the {@code equals} method and the equivalence classes defined by > 95: * the quotient of the {@code compare} method are the same. As before, suggest "equivalence class" be singular in both cases. src/java.base/share/classes/java/util/Comparator.java line 159: > 157: * and it imposes the same ordering as this comparator. Thus, > 158: * {@code comp1.equals(comp2)} implies that {@code signum(comp1.compare(o1, > 159: * o2))==signum(comp2.compare(o1, o2))} for every object reference Maybe make "signum" be a link here, similar to other locations where it's used. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2471 From smarks at openjdk.java.net Thu Feb 11 04:49:42 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 11 Feb 2021 04:49:42 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Wed, 10 Feb 2021 02:55:14 GMT, Brian Burkhalter wrote: >> This is the exact text recommended in java.lang.Comparable when a type's natural ordering is inconsistent with equals. The statement to that effect at the top of BigDecimal didn't use that exact wording > > Okay, I see. The note itself should be here, but it's demarcated with an `@apiNote` tag. This introduces a subhead "API Note:" in the rendered javadoc. Thus, it's not necessary to start the text with "Note:". ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From smarks at openjdk.java.net Thu Feb 11 04:49:43 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 11 Feb 2021 04:49:43 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:24:40 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/math/BigDecimal.java line 97: > >> 95: * contrast, the {@link equals equals} method requires both the >> 96: * numerical value and representation to be the same for equality to >> 97: * hold. > > Note, discussing "representation" is ok here since the context is discussing the representation of BigDecimal (in contrast to the text in Comparable). It might be reasonable to add a bit of rationale here and give an example. I think the reason that members of the same cohort might not be considered `equals()` to one another is that they are not substitutable. For example, consider 2.0 and 2.00. They are members of the same cohort, because new BigDecimal("2.0").compareTo(new BigDecimal("2.00")) == 0 is true. However, new BigDecimal("2.0").equals(new BigDecimal("2.00")) is false. They aren't considered `equals()` because they aren't substitutable, since using them in an arithmetic expression can give different results. For example: new BigDecimal("2.0").divide(new BigDecimal(3), RoundingMode.HALF_UP) ==> 0.7 new BigDecimal("2.00").divide(new BigDecimal(3), RoundingMode.HALF_UP) ==> 0.67 I think that's the right rationale, and a reasonable example to illustrate it. Edit to taste. I think it would be good to have material like this, though, because people's immediate reaction to BD being inconsistent with equals is "well that's wrong." Well, no, it's right, and I think this is the reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Thu Feb 11 05:40:37 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 11 Feb 2021 05:40:37 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:29:11 GMT, Stuart Marks wrote: >> Okay, I see. > > The note itself should be here, but it's demarcated with an `@apiNote` tag. This introduces a subhead "API Note:" in the rendered javadoc. Thus, it's not necessary to start the text with "Note:". My thinking here was to include the exact string "Note: this class has a natural ordering that is inconsistent with equals." in the text of BigDecimal since that is the phrase java.lang.Comparable recommends. This should improve grep-ability, etc. for such classes in the JDK. The class-level summary has a semantically equivalent statement using different wording, which left the compareTo method as a place to introduce the exact phrase. I use an @apiNote both because it is an informative statement and to prevent the text from necessarily being applied to BigDecimal subclasses. BigDecimal is not final and people can and sometimes do subclass it and those subclasses, in principle, could have a (different) natural order that was consistent with equals. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From egahlin at openjdk.java.net Thu Feb 11 07:02:41 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 11 Feb 2021 07:02:41 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. src/java.base/share/classes/java/io/ObjectInputStream.java line 1366: > 1364: DeserializationEvent event = new DeserializationEvent(); > 1365: if (event.shouldCommit()) { > 1366: event.filterStatus = status == null ? "n/a" : status.name(); We use null for missing value, so no need to have "n/a" src/java.base/share/classes/java/io/ObjectInputStream.java line 1372: > 1370: event.depth = depth; > 1371: event.bytesRead = bytesRead; > 1372: event.exception = Objects.toString(ex, "n/a"); You may want to change the name of the field to "exceptionMessage" to make it clear it's the message, not the class. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 45: > 43: > 44: @Label ("Class") > 45: public String clazz; We typically use "type" when referring to a class. src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 45: > 43: > 44: @Label ("Class") > 45: public String clazz; Is it possible to make the field of type Class? src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 51: > 49: > 50: @Label ("Reference count") > 51: public long totalObjectRefs; "Reference count" sounds a bit like resource counter? Is that the case? If not, perhaps "Object References" is better. We tried to avoid abbreviations. How about naming the field "totalObjectReferences" or just "objectReferences"? ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From shade at openjdk.java.net Thu Feb 11 07:18:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Feb 2021 07:18:39 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: On Wed, 10 Feb 2021 15:26:50 GMT, Thomas Stuefe wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment > > Looks good. I find it simpler too. > > You could run the tests with sun.reflect.inflationThreshold=0. Should increase the chance of encountering reflection delegator loaders a lot. > > Cheers, Thomas Thanks! Any reviewers from JDK side? @AlanBateman? ------------- PR: https://git.openjdk.java.net/jdk/pull/2485 From alanb at openjdk.java.net Thu Feb 11 08:07:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Feb 2021 08:07:38 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: On Wed, 10 Feb 2021 07:34:59 GMT, Aleksey Shipilev wrote: >> `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). >> >> The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. >> >> Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. >> >> On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. >> >> Additional testing: >> - [x] Ad-hoc benchmarks >> - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` >> `$ git checkout pull/2485` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment Marked as reviewed by alanb (Reviewer). src/hotspot/share/prims/jvm.cpp line 3297: > 3295: !ik->is_subclass_of(vmClasses::reflect_ConstructorAccessorImpl_klass())) { > 3296: return JNIHandles::make_local(THREAD, loader); > 3297: } This okay looks but surprised it has a measurable (or micro) difference. There has been several proposals over the years to improve latestUserDefinedLoader in the common case that OIS.resolveClass is not overridden. It may need to be looked at again. Ideally JVM_LastestUSerDefinedLoader would go away and there would be a solution based on StackWalker (but work would be required there to match the current performance). ------------- PR: https://git.openjdk.java.net/jdk/pull/2485 From shade at openjdk.java.net Thu Feb 11 08:56:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Feb 2021 08:56:40 GMT Subject: Integrated: 8261449: Micro-optimize JVM_LatestUserDefinedLoader In-Reply-To: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: <9KfR8SbKeGMyUykV1nNHXH1zL7OItaqkcXtPZBuBuz4=.55b0b979-b3d9-4b06-997d-115bc3dccaf2@github.com> On Tue, 9 Feb 2021 15:40:03 GMT, Aleksey Shipilev wrote: > `JVM_LatestUserDefinedLoader` is called normally from `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it takes a measurable time to walk the stack. There is JDK-8173368 that wants to replace it with `StackWalker`, but we can tune up the `JVM_LatestUserDefinedLoader` itself without changing the semantics of it (thus providing the backportability, including the releases that do not have `StackWalker`) and improving performance (thus providing a more aggressive baseline for `StackWalker` rewrite). > > The key is to recognize that out of two checks: 1) checking for two special subclasses; 2) checking for user classloader -- the first one usually passes, and second one fails much more frequently. First check also requires traversing the superclasses upwards looking for match. Reversing the order of the checks, plus inlining the helper method improves performance without changing the semantics. > > Out of curiosity, my previous patch dropped the first check completely, replacing it by asserts, and we definitely run into situation where that check is needed on some tests. > > On my machine, `VM.latestUserDefinedLoader` invocation time drops from 115 to 100 ns/op. Single-threaded SPECjvm2008:serial improves about 3% with this patch. > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug, `tier1`, `tier2`, `tier3` > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/2485/head:pull/2485` > `$ git checkout pull/2485` This pull request has now been integrated. Changeset: 49cf13d2 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/49cf13d2 Stats: 20 lines in 3 files changed: 4 ins; 13 del; 3 mod 8261449: Micro-optimize JVM_LatestUserDefinedLoader Reviewed-by: dholmes, stuefe, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2485 From shade at openjdk.java.net Thu Feb 11 08:56:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Feb 2021 08:56:39 GMT Subject: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader [v2] In-Reply-To: References: <3EpwZwOAE3WA0NyFG6b2UcZLdKcBihJ82eKMj0gunBE=.3435d3cc-f9f4-4994-855b-ce1ce6e6f93f@github.com> Message-ID: On Thu, 11 Feb 2021 08:04:55 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment > > Marked as reviewed by alanb (Reviewer). Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2485 From michaelm at openjdk.java.net Thu Feb 11 09:19:05 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Thu, 11 Feb 2021 09:19:05 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v9] In-Reply-To: References: Message-ID: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael Michael McMahon 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 17 additional commits since the last revision: - Merge branch 'master' into 8252971-socket-attributes - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files - Merge branch 'master' into 8252971-socket-attributes - update - fix mistake in last push - update - Merge branch 'master' into 8252971-socket-attributes - add specific check for unix domain socket - Merge branch 'master' into 8252971-socket-attributes - update - ... and 7 more: https://git.openjdk.java.net/jdk/compare/3bc0384d...11ae5e72 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2424/files - new: https://git.openjdk.java.net/jdk/pull/2424/files/70832057..11ae5e72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=07-08 Stats: 2988 lines in 123 files changed: 1583 ins; 865 del; 540 mod Patch: https://git.openjdk.java.net/jdk/pull/2424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424 PR: https://git.openjdk.java.net/jdk/pull/2424 From redestad at openjdk.java.net Thu Feb 11 10:46:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 11 Feb 2021 10:46:41 GMT Subject: RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v3] In-Reply-To: References: Message-ID: <42EyMaVpYDWoZJnJ9gMAiQ8jVo3Kr4OJ6uHVe6DPi68=.2ef23ae7-9dcd-4e18-abe5-a4458ac04691@github.com> On Wed, 10 Feb 2021 23:38:51 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about removing the generic ISO2022.Decoder > > Thanks. The newly added comment to ISO2022 is helpful. Thanks Naoto! ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From redestad at openjdk.java.net Thu Feb 11 10:46:42 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 11 Feb 2021 10:46:42 GMT Subject: Integrated: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad wrote: > This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842) > > Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding. > > Testing: tier1-3, manual runs of sun.nio.cs tests This pull request has now been integrated. Changeset: 8b6ab31d Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/8b6ab31d Stats: 761 lines in 15 files changed: 257 ins; 404 del; 100 mod 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2480 From redestad at openjdk.java.net Thu Feb 11 11:41:06 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 11 Feb 2021 11:41:06 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM [v2] In-Reply-To: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: <4ddL2LcWLk7PdgPXMPITpcLkje5n9g8QyYlKw0HPovg=.1383d9b2-c76c-4df3-8656-a64f28873cb6@github.com> > This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into checkName - Merge branch 'master' into checkName - Copyrights - Move class name checking for findBootstrapClass/findLoadedClass into native/VM ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2378/files - new: https://git.openjdk.java.net/jdk/pull/2378/files/f2fd1d1c..727b2b37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=00-01 Stats: 28701 lines in 954 files changed: 16489 ins; 8085 del; 4127 mod Patch: https://git.openjdk.java.net/jdk/pull/2378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2378/head:pull/2378 PR: https://git.openjdk.java.net/jdk/pull/2378 From shade at openjdk.java.net Thu Feb 11 12:00:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Feb 2021 12:00:39 GMT Subject: Integrated: 8261300: jpackage: rewrite while(0)/while(false) to proper blocks In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 09:17:46 GMT, Aleksey Shipilev wrote: > After JDK-8254702, SonarCloud instance complains about blocks like these: "Change this loop body so that it can be executed more than once." > > int initJvmlLauncherData(JvmlLauncherData* ptr) const { > // Store path to JLI library just behind JvmlLauncherData header. > char* curPtr = reinterpret_cast(ptr + 1); > do { > const size_t count = sizeof(char) > * (jliLibPath.size() + 1 /* trailing zero */); > if (ptr) { > std::memcpy(curPtr, jliLibPath.c_str(), count); > ptr->jliLibPath = curPtr; > } > curPtr += count; > } while (false); // <---- here > > There is no sense in having `while(false)` here, where the syntactic `{}` block would do. There are also other uses in the jpackage code that employ `while(0)` for this, and then they also trigger the inspection about the implicit conversion of zero int to boolean. > > Additional testing: > - [x] Linux x86_64 (Ubuntu) tools/jpackage This pull request has now been integrated. Changeset: 9fed6048 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9fed6048 Stats: 74 lines in 2 files changed: 0 ins; 4 del; 70 mod 8261300: jpackage: rewrite while(0)/while(false) to proper blocks Reviewed-by: herrick, asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/2454 From redestad at openjdk.java.net Thu Feb 11 12:44:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 11 Feb 2021 12:44:54 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3] In-Reply-To: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: > This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Consolidate verifyClassname and verifyFixClassname ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2378/files - new: https://git.openjdk.java.net/jdk/pull/2378/files/727b2b37..6b8305e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2378&range=01-02 Stats: 77 lines in 4 files changed: 13 ins; 40 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/2378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2378/head:pull/2378 PR: https://git.openjdk.java.net/jdk/pull/2378 From redestad at openjdk.java.net Thu Feb 11 12:44:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 11 Feb 2021 12:44:54 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3] In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Thu, 4 Feb 2021 13:14:16 GMT, Coleen Phillimore wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Consolidate verifyClassname and verifyFixClassname > > Changes requested by coleenp (Reviewer). I tried to consolidate all name checking into the native layer for the remaining methods, but there are places where we are calling the JNI code with internalized names directly through `JavaLangAccess.defineClass`, so we'd need a way to differentiate these. Seems simpler to leave the `checkName` in `preDefineClass` for now. For the JNI code consolidating verifyFixClassname and verifyClassname into a single method seems to be the most straightforward simplification possible, since these are currently called back to back. Since ASCII like `/` is never a component of a multibyte character in UTF-8 we can do the fix-up pass without validation, then do the full verification. This simplifies the code and might speed it up marginally. Also added some cleanup to the cleanup code as suggested by @tstuefe in #2407 ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From rriggs at openjdk.java.net Thu Feb 11 14:29:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 14:29:46 GMT Subject: RFR: 8261160: Add a deserialization JFR event In-Reply-To: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> References: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> Message-ID: On Wed, 10 Feb 2021 20:30:02 GMT, Roger Riggs wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Marked as reviewed by rriggs (Reviewer). As proposed, events are only created if there is a serialFilter in effect (and enabled by JFR configuration). Being able to create the events without a serialFilter in effect would be useful for monitoring, especially if it could be controlled by a separate JFR configuration option. (always, never, serial-filter , etc.) ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 14:59:11 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 14:59:11 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v2] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/ca0bcf44..8ecf63ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=00-01 Stats: 124 lines in 5 files changed: 76 ins; 2 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:08:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:08:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v2] In-Reply-To: References: <-k55MR-yzQ9SVmc_H9cu9dlWIVEyVvIrXT19-Uy4vHI=.1f56b637-b720-4606-ab08-056aa1059a76@github.com> Message-ID: On Thu, 11 Feb 2021 14:27:19 GMT, Roger Riggs wrote: >> Marked as reviewed by rriggs (Reviewer). > > As proposed, events are only created if there is a serialFilter in effect (and enabled by JFR configuration). > Being able to create the events without a serialFilter in effect would be useful for monitoring, especially if it could be controlled by a separate JFR configuration option. (always, never, serial-filter , etc.) I updated the PR and addressed all comments so far. Specifically: @RogerRiggs The generation of the event is independent of whether the filter is set or not. I also added a piece of state to determine if a filter is set or not. I think it could be useful to analyse all Deserialisation events to, say, ensure that there are none operating without a filter ( and the `filterStatus` state is ambitious in the `null` case ). @coffeys I would like GlobalFilterTest to run regardless of whether or not the jfr module is present, but of course running the test with jfr enabled is desirable too, so I added a separate at test tag for that case. @egahlin Excellent suggestions on the naming, etc. I adopted all. And added a test to ensure that the creation and generation of the event does not inadvertently trigger class initialization if the filter rejects the attempt ( thanks @dfuch ) @dfuch Thanks for the improved label suggestion, it is now merged in. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:28:07 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:28:07 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Fix failing test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/8ecf63ce..5737ee7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From coffeys at openjdk.java.net Thu Feb 11 15:47:40 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 11 Feb 2021 15:47:40 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: <1OfJdorvNMIRynW7A8A16UwuPC2qQbvA0VgYHIplhPQ=.2063d3c0-532d-49d4-9748-2e4d31df6c45@github.com> On Thu, 11 Feb 2021 15:28:07 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Thu Feb 11 15:53:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 15:53:07 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:28:07 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 42: > 40: > 41: @Label("Filter configured") > 42: public boolean filterConfigured; Should that be "Filter Configured" for consistency? ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:53:06 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:53:06 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Filter **C**onfigured ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/5737ee7c..d764f75f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Thu Feb 11 15:53:08 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 11 Feb 2021 15:53:08 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:45:33 GMT, Daniel Fuchs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing test > > src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.java line 42: > >> 40: >> 41: @Label("Filter configured") >> 42: public boolean filterConfigured; > > Should that be "Filter Configured" for consistency? Good catch. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From jlaskey at openjdk.java.net Thu Feb 11 16:02:03 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 11 Feb 2021 16:02:03 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Added table of available algorithms. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/1c17ad35..f1e3699d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=15-16 Stats: 181 lines in 3 files changed: 140 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From dfuchs at openjdk.java.net Thu Feb 11 16:04:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 11 Feb 2021 16:04:44 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:53:06 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Filter **C**onfigured LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2479 From rriggs at openjdk.java.net Thu Feb 11 16:04:45 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 16:04:45 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 15:53:06 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Filter **C**onfigured Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From rriggs at openjdk.java.net Thu Feb 11 17:18:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 17:18:49 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Message-ID: On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property and the version number provided by `sw_vers -productVersion`. When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 though the current version numbering is 11.nnn. The workaround is to derive the os.version number from the ProductBuildVersion. When the toolchain is updated to XCode 12.nnn it can be removed. The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. ------------- Commit messages: - 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 Changes: https://git.openjdk.java.net/jdk/pull/2530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253702 Stats: 30 lines in 1 file changed: 21 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 17:34:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 17:34:38 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: Message-ID: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. src/java.base/macosx/native/libjava/java_props_macosx.c line 250: > 248: > 249: NSString *nsVerStr; > 250: // Copy out the char* if running on version other than pre-10.16 Mac OS (10.16 == 11.x) Isn't the comment backwards from what the test does? I would think it should be "if running on version other than 10.16 Mac OS ...". Or am I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From bpb at openjdk.java.net Thu Feb 11 17:41:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Feb 2021 17:41:41 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> References: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> Message-ID: On Thu, 11 Feb 2021 17:31:34 GMT, Kevin Rushforth wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > src/java.base/macosx/native/libjava/java_props_macosx.c line 250: > >> 248: >> 249: NSString *nsVerStr; >> 250: // Copy out the char* if running on version other than pre-10.16 Mac OS (10.16 == 11.x) > > Isn't the comment backwards from what the test does? I would think it should be "if running on version other than 10.16 Mac OS ...". Or am I missing something? @kevinrushforth I think you are correct. This is actually mea culpa I think as I had provided in a Slack thread a failed attempt at a patch for this which contained this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From darcy at openjdk.java.net Thu Feb 11 17:41:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 11 Feb 2021 17:41:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:14:08 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Comparable.java line 110: > >> 108: * {@link Integer#signum signum}{@code (x.compareTo(y)) == -signum(y.compareTo(x))} >> 109: * for all {@code x} and {@code y}. (This >> 110: * implies that {@code x.compareTo(y)} must throw an exception iff > > I'd suggest replacing "iff" with "if and only if" because it looks like a typo, and writing out the long form emphasizes the bidirectional nature of the implication. Sure; most of the terminology in the JDK docs aren't very "math-y". ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Thu Feb 11 17:47:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 11 Feb 2021 17:47:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: <_NfM7WHb2oXQFhgHqSGULcC2SDiBTr0v86DpKOWseZ8=.4e9d1003-43e6-4e7b-8b69-4cffc49fa91a@github.com> On Thu, 11 Feb 2021 04:19:29 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 149: > >> 147: * >> 148: * @apiNote >> 149: * Note that it is generally necessary to override the {@link hashCode hashCode} > > The `@apiNote` introduces the paragraph with a subhead "API Note:" so it's a bit redundant to say "Note that...." Maybe just start with "It is generally necessary...." Agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From rriggs at openjdk.java.net Thu Feb 11 17:48:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 17:48:41 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> Message-ID: On Thu, 11 Feb 2021 17:38:42 GMT, Brian Burkhalter wrote: >> src/java.base/macosx/native/libjava/java_props_macosx.c line 250: >> >>> 248: >>> 249: NSString *nsVerStr; >>> 250: // Copy out the char* if running on version other than pre-10.16 Mac OS (10.16 == 11.x) >> >> Isn't the comment backwards from what the test does? I would think it should be "if running on version other than 10.16 Mac OS ...". Or am I missing something? > > @kevinrushforth I think you are correct. This is actually mea culpa I think as I had provided in a Slack thread a failed attempt at a patch for this which contained this comment. So the words "other than" are too subtle? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 17:51:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 17:51:41 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> Message-ID: On Thu, 11 Feb 2021 17:46:06 GMT, Roger Riggs wrote: >> @kevinrushforth I think you are correct. This is actually mea culpa I think as I had provided in a Slack thread a failed attempt at a patch for this which contained this comment. > > So the words "other than" are too subtle? It's a double negative, unless I'm reading it incorrectly: "other than pre-10.16" I interpret as "not pre-10.16" or "10.16". ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From bpb at openjdk.java.net Thu Feb 11 17:55:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Feb 2021 17:55:38 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> Message-ID: On Thu, 11 Feb 2021 17:49:09 GMT, Kevin Rushforth wrote: >> So the words "other than" are too subtle? > > It's a double negative, unless I'm reading it incorrectly: "other than pre-10.16" I interpret as "not pre-10.16" or "10.16". `// Copy out the char* if running on version 10.x, where x < 16` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From darcy at openjdk.java.net Thu Feb 11 17:58:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 11 Feb 2021 17:58:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:37:34 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/util/Comparator.java line 159: > >> 157: * and it imposes the same ordering as this comparator. Thus, >> 158: * {@code comp1.equals(comp2)} implies that {@code signum(comp1.compare(o1, >> 159: * o2))==signum(comp2.compare(o1, o2))} for every object reference > > Maybe make "signum" be a link here, similar to other locations where it's used. Okay -- I didn't want to go overboard making all the signum references links to the method, but I can change the first occurrence in Comparator.equals to a link. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From dcubed at openjdk.java.net Thu Feb 11 18:00:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 11 Feb 2021 18:00:53 GMT Subject: RFR: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java Message-ID: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> A trivial fix to ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java in order to reduce noise in the JDK17 CI. ------------- Commit messages: - 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java Changes: https://git.openjdk.java.net/jdk/pull/2531/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261604 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2531/head:pull/2531 PR: https://git.openjdk.java.net/jdk/pull/2531 From kcr at openjdk.java.net Thu Feb 11 18:04:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 18:04:37 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: <4c4mNLvvkqD2Cytiox5RlTcLg6JHORZoJlAAFGLH-VQ=.140e43b0-01b3-4f8e-855b-a92eb4668504@github.com> Message-ID: On Thu, 11 Feb 2021 17:50:20 GMT, Brian Burkhalter wrote: >> It's a double negative, unless I'm reading it incorrectly: "other than pre-10.16" I interpret as "not pre-10.16" or "10.16". > > `// Copy out the char* if running on version 10.x[.y], where x < 16` ? It will also do it if running on `11.x[.y]` (once Xcode is upgraded), right? ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From hseigel at openjdk.java.net Thu Feb 11 18:07:39 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 11 Feb 2021 18:07:39 GMT Subject: RFR: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java In-Reply-To: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> References: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> Message-ID: On Thu, 11 Feb 2021 17:55:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java > in order to reduce noise in the JDK17 CI. Looks good and trivial. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2531 From dcubed at openjdk.java.net Thu Feb 11 18:13:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 11 Feb 2021 18:13:38 GMT Subject: RFR: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java In-Reply-To: References: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> Message-ID: On Thu, 11 Feb 2021 18:04:31 GMT, Harold Seigel wrote: >> A trivial fix to ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java >> in order to reduce noise in the JDK17 CI. > > Looks good and trivial. > Thanks, Harold @hseigel - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2531 From dcubed at openjdk.java.net Thu Feb 11 18:13:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 11 Feb 2021 18:13:40 GMT Subject: Integrated: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java In-Reply-To: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> References: <6rFGXnKnGvvyOGkNEcBh-SpIeP7wS_X9D_LftdDYU8k=.fb7341ae-d061-4899-be63-f7b339553475@github.com> Message-ID: On Thu, 11 Feb 2021 17:55:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java > in order to reduce noise in the JDK17 CI. This pull request has now been integrated. Changeset: 75c8489c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/75c8489c Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/2531 From rriggs at openjdk.java.net Thu Feb 11 18:34:54 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 18:34:54 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2] In-Reply-To: References: Message-ID: > On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct double-negative in 'other than 10.16' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2530/files - new: https://git.openjdk.java.net/jdk/pull/2530/files/7ac2b6a6..c7b05857 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 18:55:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 18:55:40 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 18:34:54 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct double-negative in 'other than 10.16' src/java.base/macosx/native/libjava/java_props_macosx.c line 262: > 260: // Copy out the char* > 261: osVersionCStr = strdup([nsVerStr UTF8String]); > 262: } else if (getenv("SYSTEM_VERSION_COMPAT") == NULL) { If version is 10.16 and `SYSTEM_VERSION_COMPAT` is set, you will fall through to the pre-10.9 Mac OS code fallback. Just checking to see if that's what you intended. ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 19:15:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 19:15:42 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. I tested this, and get the following behavior on macOS 11.0.1 with a JDK compiled with Xcode 11.3.1 and your patch: SYSTEM_VERSION_COMPAT not set : 11.0 SYSTEM_VERSION_COMPAT=1 : 10.16 SYSTEM_VERSION_COMPAT=0 : 11.0.1 So the fallback path reports what could be considered a more accurate version, at least on my laptop. Since I'm not sure what is expected, you can decide what to do with this information. ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 19:15:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 19:15:43 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 18:53:08 GMT, Kevin Rushforth wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct double-negative in 'other than 10.16' > > src/java.base/macosx/native/libjava/java_props_macosx.c line 262: > >> 260: // Copy out the char* >> 261: osVersionCStr = strdup([nsVerStr UTF8String]); >> 262: } else if (getenv("SYSTEM_VERSION_COMPAT") == NULL) { > > If version is 10.16 and `SYSTEM_VERSION_COMPAT` is set, you will fall through to the pre-10.9 Mac OS code fallback. Just checking to see if that's what you intended. FWIW, it seems to work OK using the legacy fallback path (reports 10.16 if I set `SYSTEM_VERSION_COMPAT=1`). ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From rriggs at openjdk.java.net Thu Feb 11 19:15:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 19:15:44 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v2] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:09:52 GMT, Kevin Rushforth wrote: >> src/java.base/macosx/native/libjava/java_props_macosx.c line 262: >> >>> 260: // Copy out the char* >>> 261: osVersionCStr = strdup([nsVerStr UTF8String]); >>> 262: } else if (getenv("SYSTEM_VERSION_COMPAT") == NULL) { >> >> If version is 10.16 and `SYSTEM_VERSION_COMPAT` is set, you will fall through to the pre-10.9 Mac OS code fallback. Just checking to see if that's what you intended. > > FWIW, it seems to work OK using the legacy fallback path (reports 10.16 if I set `SYSTEM_VERSION_COMPAT=1`). The same version string is available from both APIs, reading from the SystemVersion.plist is a bit slower. It would be clearer to move the checking of SYSTEM_VERSION_COMPAT to the first test (line:252) so the version info does not need to be read from the files. ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From rriggs at openjdk.java.net Thu Feb 11 19:23:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 11 Feb 2021 19:23:55 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v3] In-Reply-To: References: Message-ID: > On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2530/files - new: https://git.openjdk.java.net/jdk/pull/2530/files/c7b05857..09f6fd0e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2530&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2530/head:pull/2530 PR: https://git.openjdk.java.net/jdk/pull/2530 From bpb at openjdk.java.net Thu Feb 11 19:32:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Feb 2021 19:32:40 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v3] In-Reply-To: References: Message-ID: <5LdfBN0g1QnV4RRznn9vz2qRhXCmmQZ4EnJiLQ6zo-c=.78df6531-61fd-415c-ba55-13b9e88fd358@github.com> On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From kcr at openjdk.java.net Thu Feb 11 19:32:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Feb 2021 19:32:42 GMT Subject: RFR: 8253702: BigSur java/lang/System/OsVersionTest.java: 10.16 != 11.0 [v3] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote: >> On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property >> and the version number provided by `sw_vers -productVersion`. >> >> When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 >> though the current version numbering is 11.nnn. >> >> The workaround is to derive the os.version number from the ProductBuildVersion. >> When the toolchain is updated to XCode 12.nnn it can be removed. >> The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. >> When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set Looks good. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/2530 From cushon at openjdk.java.net Thu Feb 11 19:32:41 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 11 Feb 2021 19:32:41 GMT Subject: Withdrawn: 8231436: Fix the applicability of a no-@Target annotation type In-Reply-To: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com> Message-ID: <9iftTI7kUftd5N4ey0JAdLGKO-2u7sfkkOgNrPvrOKA=.bd76d363-cd18-4ec8-9945-37d5d352dc76@github.com> On Thu, 28 Jan 2021 22:33:53 GMT, Liam Miller-Cushon wrote: > Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2303 From hseigel at openjdk.java.net Thu Feb 11 19:54:44 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 11 Feb 2021 19:54:44 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4] In-Reply-To: <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> Message-ID: On Tue, 9 Feb 2021 13:31:25 GMT, Severin Gehwolf wrote: >> This is an enhancement which solves two issues: >> >> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). >> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. >> >> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. > > Severin Gehwolf 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 seven additional commits since the last revision: > > - Fix jcheck > - Add documentation and reduce code running in the critical section > - Add some documentation > - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics > - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics > - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics > - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection Hi Severin, Thanks for doing this! Sorry for taking so long to review this change. The change looks good. Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? Also, please don't overwrite the fix for JDK-8257746. Thanks again! Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1393 From darcy at openjdk.java.net Thu Feb 11 23:05:54 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 11 Feb 2021 23:05:54 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v4] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. 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/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/2a8dd8ce..a7f1b28b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From bpb at openjdk.java.net Fri Feb 12 01:18:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 01:18:53 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: References: Message-ID: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> > Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8247918: Change'ns' to 'n' in the skip doc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2274/files - new: https://git.openjdk.java.net/jdk/pull/2274/files/0ebed6ea..2a2ceb41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2274&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2274&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2274/head:pull/2274 PR: https://git.openjdk.java.net/jdk/pull/2274 From coleenp at openjdk.java.net Fri Feb 12 02:12:43 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 12 Feb 2021 02:12:43 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3] In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Thu, 11 Feb 2021 12:44:54 GMT, Claes Redestad wrote: >> This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Consolidate verifyClassname and verifyFixClassname This more limited cleanup looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2378 From naoto at openjdk.java.net Fri Feb 12 02:55:57 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Feb 2021 02:55:57 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character Message-ID: Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. ------------- Commit messages: - 8261621: Delegate Unicode history from JLS to j.l.Character Changes: https://git.openjdk.java.net/jdk/pull/2538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261621 Stats: 37 lines in 1 file changed: 35 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538 PR: https://git.openjdk.java.net/jdk/pull/2538 From bpb at openjdk.java.net Fri Feb 12 03:07:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 03:07:39 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 02:50:35 GMT, Naoto Sato wrote: > Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. Looks fine to me. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2538 From jpai at openjdk.java.net Fri Feb 12 03:18:37 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 12 Feb 2021 03:18:37 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Tue, 2 Feb 2021 02:41:10 GMT, Brian Burkhalter wrote: >>> > The code change looks all right. >>> >>> Should I go ahead and integrate this? >> >> Actually, I didn't notice that this PR wasn't marked as reviewed. I'll wait for the review(s) then. > > I'd let it sit for a bit in case others want to comment. Ping. Anymore reviews/suggestions from anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From bpb at openjdk.java.net Fri Feb 12 03:23:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 03:23:38 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Fri, 12 Feb 2021 03:16:02 GMT, Jaikiran Pai wrote: >> I'd let it sit for a bit in case others want to comment. > > Ping. Anymore reviews/suggestions from anyone? Did you run this through the usual CI tests in all tiers? ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From jpai at openjdk.java.net Fri Feb 12 03:37:38 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 12 Feb 2021 03:37:38 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Fri, 12 Feb 2021 03:21:04 GMT, Brian Burkhalter wrote: > Did you run this through the usual CI tests in all tiers? Hello Brian, Do you mean other than the ones that have been automatically run and passed in the GitHub actions against this PR? I don't have a Windows box, but if there's some specific tests you want me to run locally, please do let me know and I'll run them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From naoto at openjdk.java.net Fri Feb 12 04:06:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Feb 2021 04:06:55 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: > Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed empty

      tag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2538/files - new: https://git.openjdk.java.net/jdk/pull/2538/files/5560a4cf..b026b5eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538 PR: https://git.openjdk.java.net/jdk/pull/2538 From joehw at openjdk.java.net Fri Feb 12 06:47:44 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 12 Feb 2021 06:47:44 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed empty

      tag Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From smarks at openjdk.java.net Fri Feb 12 07:52:39 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 12 Feb 2021 07:52:39 GMT Subject: RFR: 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion In-Reply-To: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com> References: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com> Message-ID: On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves wrote: > Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`. Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2389 From github.com+471021+marschall at openjdk.java.net Fri Feb 12 09:18:10 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Fri, 12 Feb 2021 09:18:10 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: > Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: - Replace c-style array declarations - Share work buffer between #skip and #read ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1915/files - new: https://git.openjdk.java.net/jdk/pull/1915/files/08948f93..fc29f3e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=05-06 Stats: 28 lines in 1 file changed: 8 ins; 6 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Fri Feb 12 09:20:41 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Fri, 12 Feb 2021 09:20:41 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3] In-Reply-To: <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com> References: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com> <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com> <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com> Message-ID: <1DmQcrkGvKVBZYWrsv00WwH1UT4W-xvj86uC1kHkqHA=.4164f16e-c8e3-4e4d-80e3-79d11d52c74b@github.com> On Wed, 10 Feb 2021 21:58:02 GMT, Brian Burkhalter wrote: >> That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is. >> >> We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip. > > Perhaps a static final `WORK_BUFFER_SIZE` could be added with value 8192 and `maxSkipBufferSize` and `TRANSFER_BUFFER_SIZE` replaced with that? Then `skipBuffer` could be renamed to `workBuffer` and used in both `read(CharBuffer)` and `skip(long)`. That shouldn't be a problem as both uses are in synchronized blocks. Also I suggest putting the declaration of `workBuffer` just below that of `lock` instead of lower down the file where `skipBuffer` is. > > Lastly you mentioned C-style array declarations like `char buf[]`. As there are only four of these in the file it might be good to just go ahead and change them, I don't think that adds much noise or risk. Done. I left #transferTo(Writer) untouched for now. Firstly it is not already behind a synchronized. Secondly it writes so there is no need for repeated calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From sgehwolf at openjdk.java.net Fri Feb 12 10:21:48 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 12 Feb 2021 10:21:48 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> Message-ID: On Thu, 11 Feb 2021 19:51:43 GMT, Harold Seigel wrote: >> Severin Gehwolf 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 seven additional commits since the last revision: >> >> - Fix jcheck >> - Add documentation and reduce code running in the critical section >> - Add some documentation >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics >> - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection > > Hi Severin, > Thanks for doing this! Sorry for taking so long to review this change. The change looks good. Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? Also, please don't overwrite the fix for JDK-8257746. > Thanks again! Harold Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From clanger at openjdk.java.net Fri Feb 12 11:05:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 12 Feb 2021 11:05:40 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: <51otobW2pPoE0hrya652T-QHv7O9L5KwlwsP6uLjN5M=.60533500-483b-44ba-84b8-590a752c1da4@github.com> On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage As we're potentially formatting any "Number" type here, theoretically floats could be passed which would result in an Exception. In fact, only decimal types are passed by the callers so this should not happen. Unfortunately there's no super type specifying decimal numbers. And as we're not doing some fancy formatting but just %d, I think replacing this with %s should be ok. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2483 From vkempik at openjdk.java.net Fri Feb 12 11:45:49 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 11:45:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> References: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com> Message-ID: On Thu, 4 Feb 2021 21:59:02 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194: > >> 192: // may get turned off by -fomit-frame-pointer. >> 193: frame os::get_sender_for_C_frame(frame* fr) { >> 194: return frame(fr->link(), fr->link(), fr->sender_pc()); > > Why is it > > return frame(fr->link(), fr->link(), fr->sender_pc()); > > and not > > return frame(fr->sender_sp(), fr->link(), fr->sender_pc()); > > like in the bsd-x86 counter part? bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things from bsd_x86 You think the bsd-x86 is better here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From pconcannon at openjdk.java.net Fri Feb 12 11:50:51 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 11:50:51 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview Message-ID: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Hi, Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). Kind regards, Patrick ------------- Commit messages: - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview Changes: https://git.openjdk.java.net/jdk/pull/2544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252399 Stats: 68 lines in 2 files changed: 64 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From dfuchs at openjdk.java.net Fri Feb 12 11:57:43 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 12 Feb 2021 11:57:43 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: On Fri, 12 Feb 2021 11:46:09 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick test/jdk/java/util/stream/examples/JavadocExamples.java line 59: > 57: } > 58: } > 59: private void expandIterable(Object o, Consumer c) { } It would be better to keep the second example in its original form: with class C ... etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/2544 From vkempik at openjdk.java.net Fri Feb 12 12:07:52 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:07:52 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:07:15 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195: > >> 193: frame os::get_sender_for_C_frame(frame* fr) { >> 194: return frame(fr->link(), fr->link(), fr->sender_pc()); >> 195: } > > Is this file going to be built by GCC or just macOS compilers? there is no support for compiling java with gcc on macos since about jdk11, only clang. considering this and the absence of gcc for macos_m1, the answer is - just macOS compilers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From pconcannon at openjdk.java.net Fri Feb 12 12:12:01 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 12:12:01 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v2] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Corrected Expand Iterable Example ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/39261213..1b8ca544 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=00-01 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From pconcannon at openjdk.java.net Fri Feb 12 12:12:02 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 12:12:02 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v2] In-Reply-To: References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: <0rgjmiviwzNUPXcEAUz0ejrj0WD_6FGjjkega_E1NF8=.35398ea4-c138-420b-a19e-98280751dc6b@github.com> On Fri, 12 Feb 2021 11:54:30 GMT, Daniel Fuchs wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252399: Corrected Expand Iterable Example > > test/jdk/java/util/stream/examples/JavadocExamples.java line 59: > >> 57: } >> 58: } >> 59: private void expandIterable(Object o, Consumer c) { } > > It would be better to keep the second example in its original form: with class C ... etc. Corrected this now. See 1b8ca54 ------------- PR: https://git.openjdk.java.net/jdk/pull/2544 From pconcannon at openjdk.java.net Fri Feb 12 12:16:00 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 12:16:00 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v3] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: <4LtXU99bEqyAfPt7v_iI4W7HktloRra_h4INX9Z3VRg=.6d0a8b44-516b-4b97-bd9c-9c67444fe016@github.com> > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Added more appropriate test stream for Expand Iterable example ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/1b8ca544..8f8dfe5c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From vkempik at openjdk.java.net Fri Feb 12 12:25:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:25:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:12:07 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: > >> 433: // | |\ Java thread created by VM does not have glibc >> 434: // | glibc guard page | - guard, attached Java thread usually has >> 435: // | |/ 1 glibc guard page. > > Is this code going to be built by GCC (with glibc) or will only > macOS compilers and libraries be used? only macos comiplers ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 12:25:47 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 12:25:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 22:54:42 GMT, Gerard Ziemski wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363: >> >>> 361: address pc = os::Posix::ucontext_get_pc(uc); >>> 362: >>> 363: if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means >> >> Is this TODO going to be resolved by this port? > > Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. @lewurm could you comment here please ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From forax at univ-mlv.fr Fri Feb 12 12:40:32 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 12 Feb 2021 13:40:32 +0100 (CET) Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v3] In-Reply-To: <4LtXU99bEqyAfPt7v_iI4W7HktloRra_h4INX9Z3VRg=.6d0a8b44-516b-4b97-bd9c-9c67444fe016@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> <4LtXU99bEqyAfPt7v_iI4W7HktloRra_h4INX9Z3VRg=.6d0a8b44-516b-4b97-bd9c-9c67444fe016@github.com> Message-ID: <1275662371.929497.1613133632223.JavaMail.zimbra@u-pem.fr> Hi Patrick, "Iterable" is Ok as runtime type of the classical instanceof but not in a type pattern where it is a raw type, so if (e instanceof Iterable elements) { should be if (e instanceof Iterable elements) { regards, R?mi ----- Mail original ----- > De: "Patrick Concannon" > ?: "core-libs-dev" > Envoy?: Vendredi 12 F?vrier 2021 13:16:00 > Objet: Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits > preview [v3] >> Hi, >> >> Could someone please review my changeset for JDK-8252399: 'Update mapMulti >> documentation to use type test pattern instead of instanceof once JEP 375 exits >> preview' ? >> >> This change updates the example code displayed in the API documentation for >> mapMulti to use the type test pattern introduced in >> [JEP375](https://openjdk.java.net/jeps/375). >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional > commit since the last revision: > > 8252399: Added more appropriate test stream for Expand Iterable example > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/2544/files > - new: https://git.openjdk.java.net/jdk/pull/2544/files/1b8ca544..8f8dfe5c > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=02 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=01-02 > > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/2544.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 > > PR: https://git.openjdk.java.net/jdk/pull/2544 From fweimer at openjdk.java.net Fri Feb 12 12:42:48 2021 From: fweimer at openjdk.java.net (Florian Weimer) Date: Fri, 12 Feb 2021 12:42:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: >> >>> 433: // | |\ Java thread created by VM does not have glibc >>> 434: // | glibc guard page | - guard, attached Java thread usually has >>> 435: // | |/ 1 glibc guard page. >> >> Is this code going to be built by GCC (with glibc) or will only >> macOS compilers and libraries be used? > > only macos comiplers The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From sgehwolf at openjdk.java.net Fri Feb 12 12:49:01 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 12 Feb 2021 12:49:01 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5] In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add comment to parsing logic of /proc/self/cgroup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/9a2d6a20..078e16db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393 From sgehwolf at openjdk.java.net Fri Feb 12 12:51:41 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 12 Feb 2021 12:51:41 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> Message-ID: On Fri, 12 Feb 2021 10:19:03 GMT, Severin Gehwolf wrote: >> Hi Severin, >> Thanks for doing this! Sorry for taking so long to review this change. The change looks good. Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? Also, please don't overwrite the fix for JDK-8257746. >> Thanks again! Harold > > Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. Hi Harold, > Thanks for doing this! Sorry for taking so long to review this change. The change looks good. Thanks for the review! > Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? Done. > Also, please don't overwrite the fix for JDK-8257746. AFAIK this patch doesn't touch this code. So this should not happen (overwrite of the fix). FWIW, once this is in I intend to propose a patch which adds a regression test for JDK-8257746. It would depend on this change. Thanks, Severin ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From alanb at openjdk.java.net Fri Feb 12 12:59:47 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Feb 2021 12:59:47 GMT Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain sockets [v9] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 09:19:05 GMT, Michael McMahon wrote: >> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. >> >> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. >> >> Thanks, >> Michael > > Michael McMahon 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 17 additional commits since the last revision: > > - Merge branch 'master' into 8252971-socket-attributes > - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files > - Merge branch 'master' into 8252971-socket-attributes > - update > - fix mistake in last push > - update > - Merge branch 'master' into 8252971-socket-attributes > - add specific check for unix domain socket > - Merge branch 'master' into 8252971-socket-attributes > - update > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c6c9f6f9...11ae5e72 Thanks for the updates, I think you've got this to a good place now. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2424 From michaelm at openjdk.java.net Fri Feb 12 13:12:43 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Fri, 12 Feb 2021 13:12:43 GMT Subject: Integrated: 8252971: WindowsFileAttributes does not know about Unix domain sockets In-Reply-To: References: Message-ID: On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote: > Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it. > > The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that. > > Thanks, > Michael This pull request has now been integrated. Changeset: 9ffabf30 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/9ffabf30 Stats: 245 lines in 10 files changed: 228 ins; 10 del; 7 mod 8252971: WindowsFileAttributes does not know about Unix domain sockets Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2424 From vkempik at openjdk.java.net Fri Feb 12 13:35:48 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 13:35:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:14:42 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486: > >> 484: } >> 485: } >> 486: } > > This appears to be a mix for Mavericks (10.9) and 10.12 > work arounds. Is this code needed by this project? I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround Gerard, 8020753 was originally your fix, do you know if it still needed on intel-mac ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 12 13:46:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Feb 2021 13:46:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v13] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/0d0e9baf..ad4e4c65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Fri Feb 12 13:50:49 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 12 Feb 2021 13:50:49 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323: >> >>> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset())); >>> 322: >>> 323: str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset())); >> >> I don't think this switch from `JavaThread::saved_fp_address_offset()` >> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since >> `rthread` is still used and is a JavaThread*. The new code will give you: >> >> `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor >> >> The old code gave you: >> >> `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread >> >> Those are not the same things. > > I agree, I don't understand why this change was made. Wow, this is scary. I don't understand how I've merged JDK-8257882 like this. I've reviewed cpu/aarch64 changes again, there is nothing suspicious besides this. Thank you very much for catching, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 12 14:07:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 14:07:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 22:08:14 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 221: > >> 219: assert(sig == info->si_signo, "bad siginfo"); >> 220: } >> 221: */ > > Should this code be deleted? From here and from where it was copied > from if it is also commented out there... Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr - https://github.com/openjdk/jdk/pull/2547 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From rriggs at openjdk.java.net Fri Feb 12 15:24:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 15:24:41 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed empty

      tag The table is informative and should not be construed as specification. The wording "has supported" should be sufficient. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2538 From vkempik at openjdk.java.net Fri Feb 12 15:25:54 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 12 Feb 2021 15:25:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com> On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > >> 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); >> 296: } >> 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { > > Can we add a comment here describing what this case means? this arm64 specific part came as is from linux_aarch64 and I can't add any meaning comments here. > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302: > >> 300: const uint64_t *detail_msg_ptr >> 301: = (uint64_t*)(pc + NativeInstruction::instruction_size); >> 302: const char *detail_msg = (const char *)*detail_msg_ptr; > > Where is `detail_msg` used? Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in report_and_die But became unused on bsd_arm64. I agree this needs to be removed > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403: > >> 401: } >> 402: >> 403: return false; // Mute compiler > > Is this comment needed? this part came as is from linux_aarch64 as well and was supposed to mean something there. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From pconcannon at openjdk.java.net Fri Feb 12 15:40:59 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 15:40:59 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v4] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8252399 - 8252399: Added more appropriate test stream for Expand Iterable example - 8252399: Corrected Expand Iterable Example - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/8f8dfe5c..f7003778 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=02-03 Stats: 717 lines in 21 files changed: 651 ins; 20 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From pconcannon at openjdk.java.net Fri Feb 12 15:59:01 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 15:59:01 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v5] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 825399: Added wildcard to Iterable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/f7003778..80056650 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From pconcannon at openjdk.java.net Fri Feb 12 15:59:01 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 15:59:01 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: On Fri, 12 Feb 2021 11:46:09 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick > _Mailing list message from [Remi Forax](mailto:forax at univ-mlv.fr) on [core-libs-dev](mailto:core-libs-dev at openjdk.java.net):_ > > Hi Patrick, > > "Iterable" is Ok as runtime type of the classical instanceof but not in a type pattern where it is a raw type, > so > if (e instanceof Iterable elements) { > should be > if (e instanceof Iterable elements) { > > regards, > R?mi > > ----- Mail original ----- > > > De: "Patrick Concannon" > > ?: "core-libs-dev" > > Envoy?: Vendredi 12 F?vrier 2021 13:16:00 > > Objet: Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits > > preview [v3] Hi Remi, Well spotted. I've updated that now ... you can view the change here: 8005665 ------------- PR: https://git.openjdk.java.net/jdk/pull/2544 From igraves at openjdk.java.net Fri Feb 12 16:09:42 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 12 Feb 2021 16:09:42 GMT Subject: Integrated: 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion In-Reply-To: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com> References: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com> Message-ID: On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves wrote: > Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`. This pull request has now been integrated. Changeset: 350303d4 Author: Ian Graves Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/350303d4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/2389 From rriggs at openjdk.java.net Fri Feb 12 16:14:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 16:14:44 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> References: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> Message-ID: On Fri, 12 Feb 2021 01:18:53 GMT, Brian Burkhalter wrote: >> Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8247918: Change'ns' to 'n' in the skip doc The use of @ inheritdoc causes some unexpected changes in the javadoc, dropping the skip method from several classes. src/java.base/share/classes/java/io/StringReader.java line 108: > 106: > 107: /** > 108: * {@inheritDoc} Using inheritDoc for the exceptions adds several new and irrelevant impossible causes to the javadoc. " This method will block until some characters are available", etc. src/java.base/share/classes/java/io/PushbackReader.java line 257: > 255: > 256: /** > 257: * {@inheritDoc} This appears to make the skip method disappear from the PushbackReader javadoc and only show up as a method declared in FilterReader. src/java.base/share/classes/java/io/LineNumberReader.java line 270: > 268: > 269: /** > 270: * {@inheritDoc} This appears to make the skip method disappear from the LineNumberReader javadoc and only show up as a method declared in Reader. src/java.base/share/classes/java/io/CharArrayReader.java line 149: > 147: > 148: /** > 149: * {@inheritDoc} Using inheritDoc for the exceptions adds several new and irrelevant impossible causes to the javadoc. " This method will block until some characters are available", etc. It also drops the existing "If the stream is closed" condition on @ throws IOException. src/java.base/share/classes/java/io/BufferedReader.java line 400: > 398: > 399: /** > 400: * {@inheritDoc} This appears to make the skip method disappear from the BufferedReader javadoc and only show up as a method declared in Reader. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From alanb at openjdk.java.net Fri Feb 12 16:15:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Feb 2021 16:15:41 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed empty

      tag src/java.base/share/classes/java/lang/Character.java line 86: > 84: * Unicode 10.0 > 85: * Java SE 9 > 86: * Unicode 8.0 Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release? ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From chegar at openjdk.java.net Fri Feb 12 16:26:09 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 16:26:09 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: References: Message-ID: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Split exception into type and message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files - new: https://git.openjdk.java.net/jdk/pull/2479/files/d764f75f..8cb8f75e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2479&range=03-04 Stats: 48 lines in 4 files changed: 34 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2479/head:pull/2479 PR: https://git.openjdk.java.net/jdk/pull/2479 From chegar at openjdk.java.net Fri Feb 12 16:26:10 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 16:26:10 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v4] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:09 GMT, Roger Riggs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: >> >> Filter **C**onfigured > > Marked as reviewed by rriggs (Reviewer). Speaking to Erik offline, he suggested to split the `exceptionMessage` into `exceptionType` and `exceptionMessage` ( since the code was somewhat overloading the existing Sting field by using toString to force the exception class name and message into a single sting ). While the exceptionXXX field should rarely be non-null, they add very little overhead. ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From bpb at openjdk.java.net Fri Feb 12 16:39:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 16:39:43 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: References: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> Message-ID: On Fri, 12 Feb 2021 15:51:59 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247918: Change'ns' to 'n' in the skip doc > > src/java.base/share/classes/java/io/StringReader.java line 108: > >> 106: >> 107: /** >> 108: * {@inheritDoc} > > Using inheritDoc for the exceptions adds several new and irrelevant impossible causes to the javadoc. > " This method will block until some characters are available", etc. Good catch; will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From rriggs at openjdk.java.net Fri Feb 12 16:40:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 16:40:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From bpb at openjdk.java.net Fri Feb 12 16:43:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 16:43:44 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: References: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> Message-ID: On Fri, 12 Feb 2021 16:03:09 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247918: Change'ns' to 'n' in the skip doc > > src/java.base/share/classes/java/io/LineNumberReader.java line 270: > >> 268: >> 269: /** >> 270: * {@inheritDoc} > > This appears to make the skip method disappear from the LineNumberReader javadoc > and only show up as a method declared in Reader. Right. This is intended and expected. > src/java.base/share/classes/java/io/CharArrayReader.java line 149: > >> 147: >> 148: /** >> 149: * {@inheritDoc} > > Using inheritDoc for the exceptions adds several new and irrelevant impossible causes to the javadoc. > " This method will block until some characters are available", etc. > It also drops the existing "If the stream is closed" condition on @ throws IOException. As above for `StringReader`. > src/java.base/share/classes/java/io/PushbackReader.java line 257: > >> 255: >> 256: /** >> 257: * {@inheritDoc} > > This appears to make the skip method disappear from the PushbackReader javadoc > and only show up as a method declared in FilterReader. This is intended and expected. > src/java.base/share/classes/java/io/BufferedReader.java line 400: > >> 398: >> 399: /** >> 400: * {@inheritDoc} > > This appears to make the skip method disappear from the BufferedReader javadoc > and only show up as a method declared in Reader. This is intended and expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From rriggs at openjdk.java.net Fri Feb 12 16:45:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 16:45:42 GMT Subject: Integrated: 8253702: BigSur version number reported as 10.16, should be 11.nn In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 17:14:35 GMT, Roger Riggs wrote: > On Mac Os X, the OSVersionTest detected a difference in the version number reported in the os.version property > and the version number provided by `sw_vers -productVersion`. > > When the java runtime is built with XCode 11.3, the os.version is reported as 10.16 > though the current version numbering is 11.nnn. > > The workaround is to derive the os.version number from the ProductBuildVersion. > When the toolchain is updated to XCode 12.nnn it can be removed. > The workaround is enabled only when the environment variable SYSTEM_VERSION_COMPAT is unset. > When the SYSTEM_VERSION_COMPAT is set in the environment the version number is reported as reported by Mac OS X. This pull request has now been integrated. Changeset: 66757750 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/66757750 Stats: 30 lines in 1 file changed: 22 ins; 2 del; 6 mod 8253702: BigSur version number reported as 10.16, should be 11.nn Reviewed-by: bpb, kcr ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From coffeys at openjdk.java.net Fri Feb 12 16:52:42 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Fri, 12 Feb 2021 16:52:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From dfuchs at openjdk.java.net Fri Feb 12 16:58:42 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 12 Feb 2021 16:58:42 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From egahlin at openjdk.java.net Fri Feb 12 17:03:47 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 12 Feb 2021 17:03:47 GMT Subject: RFR: 8261160: Add a deserialization JFR event [v5] In-Reply-To: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> References: <-pXjXPn88r-DfcKsgNYvH43wgIChfIfUHanFLYZNLt4=.088fc282-17ca-4148-b3ec-f2c0909b6aa8@github.com> Message-ID: On Fri, 12 Feb 2021 16:26:09 GMT, Chris Hegarty wrote: >> This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. > > Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: > > Split exception into type and message Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From naoto at openjdk.java.net Fri Feb 12 17:06:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Feb 2021 17:06:44 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 16:13:04 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed empty

      tag > > src/java.base/share/classes/java/lang/Character.java line 86: > >> 84: * Unicode 10.0 >> 85: * Java SE 9 >> 86: * Unicode 8.0 > > Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release? This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From bpb at openjdk.java.net Fri Feb 12 17:25:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 17:25:00 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v3] In-Reply-To: References: Message-ID: > Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8247918: Remove verbiage describing impossible behavior in CharArrayReader and StringReader ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2274/files - new: https://git.openjdk.java.net/jdk/pull/2274/files/2a2ceb41..a33245d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2274&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2274&range=01-02 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2274/head:pull/2274 PR: https://git.openjdk.java.net/jdk/pull/2274 From chegar at openjdk.java.net Fri Feb 12 17:38:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 12 Feb 2021 17:38:40 GMT Subject: Integrated: 8261160: Add a deserialization JFR event In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The event also captures the filter status, if there is one. This pull request has now been integrated. Changeset: 3dc6f52a Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/3dc6f52a Stats: 620 lines in 12 files changed: 598 ins; 5 del; 17 mod 8261160: Add a deserialization JFR event Co-authored-by: Sean Coffey Co-authored-by: Chris Hegarty Reviewed-by: coffeys, rriggs, dfuchs, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/2479 From github.com+7806504+liach at openjdk.java.net Fri Feb 12 17:45:46 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Fri, 12 Feb 2021 17:45:46 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: References: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> Message-ID: On Fri, 12 Feb 2021 16:11:58 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247918: Change'ns' to 'n' in the skip doc > > The use of @ inheritdoc causes some unexpected changes in the javadoc, dropping the skip method from several classes. I personally suggest moving this clarification into a separate paragraph as opposed to appending it to the first sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From brian.burkhalter at oracle.com Fri Feb 12 18:23:26 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Feb 2021 10:23:26 -0800 Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v2] In-Reply-To: References: <8lb2-dk7C3L98EfK1nfoDS1swFiyriHaFMO4MS4RUzg=.df1e9be1-e2c2-4658-94f6-2dc684d02a64@github.com> Message-ID: I would be all right with that. > On Feb 12, 2021, at 9:45 AM, liach wrote: > > On Fri, 12 Feb 2021 16:11:58 GMT, Roger Riggs wrote: > >>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >>> >>> 8247918: Change'ns' to 'n' in the skip doc >> >> The use of @ inheritdoc causes some unexpected changes in the javadoc, dropping the skip method from several classes. > > I personally suggest moving this clarification into a separate paragraph as opposed to appending it to the first sentence. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2274 From github.com+1059453+fleshgrinder at openjdk.java.net Fri Feb 12 19:15:41 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Fri, 12 Feb 2021 19:15:41 GMT Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: <3-wkodUcgfRa4uO368j9YI94T7pVj0waG5fryDD1rzU=.c709490e-58f0-4a01-8bd5-b516c4be4ab5@github.com> Message-ID: On Fri, 15 Jan 2021 07:14:49 GMT, Richard Fussenegger wrote: >> Often an enhancement is created when there's an idea of an improvement but no resources to do the research and develop a justification. That work has to be done when someone has time. Usually ideas are discussed on one of the many OpenJDK email aliases to validate the idea and the approach before developing the code. See the list of OpenJDK Mail lists for details. >> https://mail.openjdk.java.net/mailman/listinfo >> As for moving to GitHub, it was in part to make it easier to collaborate on the development but also to move from Mercurial to Git. >> But GitHub does not replace the need for discussion on the Email Lists. > > Active Active ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From alanb at openjdk.java.net Fri Feb 12 19:33:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Feb 2021 19:33:40 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! @JarvisCraft Can you re-run your benchmarks in light of the changes that @cl4es pointed out in the previous comment? We think this PR can be closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From pconcannon at openjdk.java.net Fri Feb 12 20:22:58 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 20:22:58 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v6] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon 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 remote-tracking branch 'origin/master' into JDK-8252399 - 825399: Added wildcard to Iterable - Merge remote-tracking branch 'origin/master' into JDK-8252399 - 8252399: Added more appropriate test stream for Expand Iterable example - 8252399: Corrected Expand Iterable Example - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/80056650..2429e4f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=04-05 Stats: 736 lines in 25 files changed: 669 ins; 31 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From pconcannon at openjdk.java.net Fri Feb 12 20:27:00 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 12 Feb 2021 20:27:00 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7] In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> Message-ID: <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> > Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? > > This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8252399: Converted JavadocExamples to test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2544/files - new: https://git.openjdk.java.net/jdk/pull/2544/files/2429e4f7..47dd74df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=05-06 Stats: 33 lines in 2 files changed: 15 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/2544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544 PR: https://git.openjdk.java.net/jdk/pull/2544 From darcy at openjdk.java.net Fri Feb 12 20:32:38 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 20:32:38 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: Message-ID: <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com> On Fri, 12 Feb 2021 17:03:57 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/Character.java line 86: >> >>> 84: * Unicode 10.0 >>> 85: * Java SE 9 >>> 86: * Unicode 8.0 >> >> Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release? > > This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here. Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version? ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov wrote: >> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. >> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk > > I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) > and checked tier2 and tier3. > What I got: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > >> jtreg:test/jdk:tier2 3698 3690 6 2 << > >> jtreg:test/langtools:tier2 12 11 1 0 << > jtreg:test/jaxp:tier2 450 450 0 0 > ============================== > TEST FAILURE > > > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > >> jtreg:test/jdk:tier3 1190 1188 2 0 << > jtreg:test/langtools:tier3 0 0 0 0 > jtreg:test/jaxp:tier3 0 0 0 0 > ============================== > TEST FAILURE > > > Failed tests: > > tier2: > java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. > java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information > java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr > tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > > sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details > sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details > > jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > tier3: > sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 Then I tried to run tests separately: ## java/io/File/GetXSpace.java make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" STDERR: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) at java.base/java.io.File.toPath(File.java:2316) at GetXSpace.compare(GetXSpace.java:219) at GetXSpace.testDF(GetXSpace.java:394) at GetXSpace.main(GetXSpace.java:428) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.nio.file.InvalidPathException JavaTest Message: shutting down test STDOUT: --- Testing df C:/Programs/cygwin64 350809332 172573816 178235516 50% / D: 3702215676 2812548988 889666688 76% /cygdrive/d E: 3906885628 3544182676 362702952 91% /cygdrive/e F: 250057724 240917056 9140668 97% /cygdrive/f SecurityManager = null C:/Programs/cygwin64: df total= 359228755968 free = 0 usable = 182513168384 getX total= 359228755968 free = 182513168384 usable = 182513168384 :: df total= 3791068852224 free = 0 usable = 911018688512 getX total= 0 free = 0 usable = 0 TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : -------------------------------------------------- https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov wrote: >> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) >> and checked tier2 and tier3. >> What I got: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> >> jtreg:test/jdk:tier2 3698 3690 6 2 << >> >> jtreg:test/langtools:tier2 12 11 1 0 << >> jtreg:test/jaxp:tier2 450 450 0 0 >> ============================== >> TEST FAILURE >> >> >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> >> jtreg:test/jdk:tier3 1190 1188 2 0 << >> jtreg:test/langtools:tier3 0 0 0 0 >> jtreg:test/jaxp:tier3 0 0 0 0 >> ============================== >> TEST FAILURE >> >> >> Failed tests: >> >> tier2: >> java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. >> java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information >> java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr >> tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> >> sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details >> sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details >> >> jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 >> >> tier3: >> sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 >> sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > Then I tried to run tests separately: > ## java/io/File/GetXSpace.java > > > make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" > > STDERR: > java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) > at java.base/java.io.File.toPath(File.java:2316) > at GetXSpace.compare(GetXSpace.java:219) > at GetXSpace.testDF(GetXSpace.java:394) > at GetXSpace.main(GetXSpace.java:428) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.nio.file.InvalidPathException > JavaTest Message: shutting down test > > STDOUT: > --- Testing df > C:/Programs/cygwin64 350809332 172573816 178235516 50% / > D: 3702215676 2812548988 889666688 76% /cygdrive/d > E: 3906885628 3544182676 362702952 91% /cygdrive/e > F: 250057724 240917056 9140668 97% /cygdrive/f > > > SecurityManager = null > C:/Programs/cygwin64: > df total= 359228755968 free = 0 usable = 182513168384 > getX total= 359228755968 free = 182513168384 usable = 182513168384 > :: > df total= 3791068852224 free = 0 usable = 911018688512 > getX total= 0 free = 0 usable = 0 > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : > -------------------------------------------------- > > > https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. ## java/net/MulticastSocket/MulticastAddresses.java make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" STDOUT: Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /129.1.1.1 joinGroup(InetAddress) Passed: Not a multicast address Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Failed: No route to host: no further information Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Passed. joinGroup(InetAddress,NetworkInterface) Passed. Test: /0:0:0:0:0:0:0:1 joinGroup(InetAddress) Passed: Not a multicast address Test: /0:0:0:0:0:0:8101:101 joinGroup(InetAddress) Passed: Not a multicast address Test: /fe80:0:0:0:a00:20ff:fee5:bc02 joinGroup(InetAddress) Passed: Not a multicast address STDERR: java.lang.Exception: 1 test(s) failed - see log file. at MulticastAddresses.runTest(MulticastAddresses.java:93) at MulticastAddresses.main(MulticastAddresses.java:138) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. I connected debbuger and got this stack trace: java.net.NoRouteToHostException: No route to host: no further information at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) at java.base/sun.nio.ch.Net.join6(Net.java:734) at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) at MulticastAddresses.runTest(MulticastAddresses.java:56) at MulticastAddresses.main(MulticastAddresses.java:138) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) Not sure what actual cause. Will investigate further. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:09:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:09:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: Message-ID: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes wrote: >> The other security-related code changes look good to me. > > I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. > As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33) and checked tier2 and tier3. What I got: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier2 3698 3690 6 2 << >> jtreg:test/langtools:tier2 12 11 1 0 << jtreg:test/jaxp:tier2 450 450 0 0 ============================== TEST FAILURE ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk:tier3 1190 1188 2 0 << jtreg:test/langtools:tier3 0 0 0 0 jtreg:test/jaxp:tier3 0 0 0 0 ============================== TEST FAILURE Failed tests: tier2: java/io/File/GetXSpace.java Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : java/net/MulticastSocket/MulticastAddresses.java Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. java/net/MulticastSocket/SetLoopbackMode.java Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information java/nio/file/Files/CopyAndMove.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected java/security/AccessController/DoPrivAccompliceTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS sun/security/tools/jarsigner/TimestampCheck.java Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details sun/security/tools/keytool/DefaultOptions.java Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details jdk/jshell/ToolBasicTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 tier3: sanity/client/SwingSet/src/SwingSet2DemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 sanity/client/SwingSet/src/ColorChooserDemoTest.java Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:14:40 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:14:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> Message-ID: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov wrote: >> Then I tried to run tests separately: >> ## java/io/File/GetXSpace.java >> >> >> make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java" >> >> STDERR: >> java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) >> at java.base/java.io.File.toPath(File.java:2316) >> at GetXSpace.compare(GetXSpace.java:219) >> at GetXSpace.testDF(GetXSpace.java:394) >> at GetXSpace.main(GetXSpace.java:428) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.nio.file.InvalidPathException >> JavaTest Message: shutting down test >> >> STDOUT: >> --- Testing df >> C:/Programs/cygwin64 350809332 172573816 178235516 50% / >> D: 3702215676 2812548988 889666688 76% /cygdrive/d >> E: 3906885628 3544182676 362702952 91% /cygdrive/e >> F: 250057724 240917056 9140668 97% /cygdrive/f >> >> >> SecurityManager = null >> C:/Programs/cygwin64: >> df total= 359228755968 free = 0 usable = 182513168384 >> getX total= 359228755968 free = 182513168384 usable = 182513168384 >> :: >> df total= 3791068852224 free = 0 usable = 911018688512 >> getX total= 0 free = 0 usable = 0 >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: : >> -------------------------------------------------- >> >> >> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output. > > ## java/net/MulticastSocket/MulticastAddresses.java > > make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" > > STDOUT: > Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /129.1.1.1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Failed: No route to host: no further information > Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Passed. > joinGroup(InetAddress,NetworkInterface) Passed. > Test: /0:0:0:0:0:0:0:1 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /0:0:0:0:0:0:8101:101 > joinGroup(InetAddress) > Passed: Not a multicast address > Test: /fe80:0:0:0:a00:20ff:fee5:bc02 > joinGroup(InetAddress) > Passed: Not a multicast address > STDERR: > java.lang.Exception: 1 test(s) failed - see log file. > at MulticastAddresses.runTest(MulticastAddresses.java:93) > at MulticastAddresses.main(MulticastAddresses.java:138) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. > > > I connected debbuger and got this stack trace: > > java.net.NoRouteToHostException: No route to host: no further information > at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) > at java.base/sun.nio.ch.Net.join6(Net.java:734) > at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) > at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) > at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) > at MulticastAddresses.runTest(MulticastAddresses.java:56) > at MulticastAddresses.main(MulticastAddresses.java:138) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > Not sure what actual cause. Will investigate further. ## java/net/MulticastSocket/SetLoopbackMode.java make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" STDOUT: IPv6 can be used Default network interface: null Test will use multicast group: /ff01:0:0:0:0:0:0:1 NetworkInterface.getByInetAddress(grp): null STDERR: java.net.NoRouteToHostException: No route to host: no further information at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) at java.base/sun.nio.ch.Net.join6(Net.java:734) at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) at SetLoopbackMode.main(SetLoopbackMode.java:132) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information Cause looks similar to `MulticastAddresses`: virtualbox network interface: Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) joinGroup(InetAddress) Failed: No route to host: no further information Will investigate futher. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:34:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:34:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov wrote: >> ## java/net/MulticastSocket/MulticastAddresses.java >> >> make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java" >> >> STDOUT: >> Test: /224.80.80.80 ni: name:eth1 (PANGP Virtual Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /129.1.1.1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Failed: No route to host: no further information >> Test: /ff02:0:0:0:0:0:0:1234 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff05:0:0:0:0:0:0:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /ff0e:0:0:0:0:0:1234:a ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Passed. >> joinGroup(InetAddress,NetworkInterface) Passed. >> Test: /0:0:0:0:0:0:0:1 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /0:0:0:0:0:0:8101:101 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> Test: /fe80:0:0:0:a00:20ff:fee5:bc02 >> joinGroup(InetAddress) >> Passed: Not a multicast address >> STDERR: >> java.lang.Exception: 1 test(s) failed - see log file. >> at MulticastAddresses.runTest(MulticastAddresses.java:93) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.Exception >> JavaTest Message: shutting down test >> >> >> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file. >> >> >> I connected debbuger and got this stack trace: >> >> java.net.NoRouteToHostException: No route to host: no further information >> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) >> at java.base/sun.nio.ch.Net.join6(Net.java:734) >> at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) >> at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) >> at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) >> at MulticastAddresses.runTest(MulticastAddresses.java:56) >> at MulticastAddresses.main(MulticastAddresses.java:138) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> Not sure what actual cause. Will investigate further. > > ## java/net/MulticastSocket/SetLoopbackMode.java > > make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" > > > STDOUT: > IPv6 can be used > Default network interface: null > > Test will use multicast group: /ff01:0:0:0:0:0:0:1 > NetworkInterface.getByInetAddress(grp): null > STDERR: > java.net.NoRouteToHostException: No route to host: no further information > at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) > at java.base/sun.nio.ch.Net.join6(Net.java:734) > at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) > at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) > at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) > at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) > at SetLoopbackMode.main(SetLoopbackMode.java:132) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information > > Cause looks similar to `MulticastAddresses`: virtualbox network interface: > Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) > joinGroup(InetAddress) Failed: No route to host: no further information > Will investigate futher. ## java/nio/file/Files/CopyAndMove.java make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" STDOUT: Seed from RandomFactory = 704532001916725417L STDERR: dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) dir2: .\name1900089232270637553 (NTFS) java.lang.RuntimeException: AtomicMoveNotSupportedException expected at CopyAndMove.testMove(CopyAndMove.java:369) at CopyAndMove.main(CopyAndMove.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected Checked in debugger: Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" sameDevice = false https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From naoto at openjdk.java.net Fri Feb 12 21:46:39 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 12 Feb 2021 21:46:39 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com> References: <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com> Message-ID: On Fri, 12 Feb 2021 20:29:28 GMT, Joe Darcy wrote: >> This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here. > > Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version? I thought about that but decided not to include them here because the changes made in those MRs were not Unicode version upgrades (i.e., version stayed the same). Let me know if you think otherwise. ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 21:55:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 21:55:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov wrote: >> ## java/net/MulticastSocket/SetLoopbackMode.java >> >> make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java" >> >> >> STDOUT: >> IPv6 can be used >> Default network interface: null >> >> Test will use multicast group: /ff01:0:0:0:0:0:0:1 >> NetworkInterface.getByInetAddress(grp): null >> STDERR: >> java.net.NoRouteToHostException: No route to host: no further information >> at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method) >> at java.base/sun.nio.ch.Net.join6(Net.java:734) >> at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515) >> at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532) >> at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479) >> at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318) >> at SetLoopbackMode.main(SetLoopbackMode.java:132) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information >> >> Cause looks similar to `MulticastAddresses`: virtualbox network interface: >> Test: /ff01:0:0:0:0:0:0:1 ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter) >> joinGroup(InetAddress) Failed: No route to host: no further information >> Will investigate futher. > > ## java/nio/file/Files/CopyAndMove.java > > make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" > > STDOUT: > Seed from RandomFactory = 704532001916725417L > STDERR: > dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) > dir2: .\name1900089232270637553 (NTFS) > java.lang.RuntimeException: AtomicMoveNotSupportedException expected > at CopyAndMove.testMove(CopyAndMove.java:369) > at CopyAndMove.main(CopyAndMove.java:74) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected > > Checked in debugger: > > Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" > Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" > sameDevice = false > > https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. ## java/security/AccessController/DoPrivAccompliceTest.java make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" STDOUT: Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 STDERR: stdout: []; stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) at java.base/java.lang.System.getProperty(System.java:833) at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at DoPrivAccomplice.go(DoPrivAccomplice.java:30) at DoPrivTest.main(DoPrivTest.java:29) ] exitValue = 1 java.lang.RuntimeException: 'user' found in stderr at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr Looks like test is not ready for username `user`, which I use locally. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From darcy at openjdk.java.net Fri Feb 12 21:56:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 21:56:42 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:09:16 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Comparable.java line 68: > >> 66: * orderings that are consistent with equals. One exception is >> 67: * {@link java.math.BigDecimal}, whose {@linkplain java.math.BigDecimal#compareTo natural ordering} equates >> 68: * {@code BigDecimal} objects with equal numerical values and different representations > > Nothing here talks about the representation of BigDecimal. I think it would be preferable to say that in BigDecimal, the `equals()` method considers 4.0 and 4.00 unequal because they have different precisions; however, `compareTo()` considers them equal because it considers only their numerical values. In BigDecimal, I'll add a sentence: " The results of methods like {@link scale} and {@link unscaledValue} will differ for numerically equal values with different representations." Talking about "precision" and BigDecimal is more appropriate for pre-JSR 13 BigDecimal since values like zero can have the same precision (1 digit) but many different scales. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Fri Feb 12 22:15:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:15:42 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:12:06 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Comparable.java line 90: > >> 88: * of the {@code equals} method and the equivalence classes defined by >> 89: * the quotient of the {@code compareTo} method are the same. >> 90: * > > I think in both cases it should be "the equivalence class defined by...." That is, "equivalence class" should be singular. But there are two of them, so the sentence still properly concludes "... are the same." An equivalence relation defines a *set* of equivalence classes which partition the objects the relation operates on. For example, the "same signum value" equivalence relation on integers has three equivalence classes : 1) negative nonzero numbers (corresponding to signum == -1) 2) zero (corresponding to signum = 0) 3) positive nonzero numbers (corresponding to signum ==1) ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 12 22:15:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 12 Feb 2021 22:15:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov wrote: >> ## java/nio/file/Files/CopyAndMove.java >> >> make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java" >> >> STDOUT: >> Seed from RandomFactory = 704532001916725417L >> STDERR: >> dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS) >> dir2: .\name1900089232270637553 (NTFS) >> java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> at CopyAndMove.testMove(CopyAndMove.java:369) >> at CopyAndMove.main(CopyAndMove.java:74) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected >> >> Checked in debugger: >> >> Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)" >> Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)" >> sameDevice = false >> >> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test. > > ## java/security/AccessController/DoPrivAccompliceTest.java > > make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" > > STDOUT: > Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > > Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > > Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar > Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] > [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 > [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 > [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 > Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' > [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 > [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 > Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar > Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] > [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 > [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 > Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' > [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 > [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 > STDERR: > stdout: []; > stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) > at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) > at java.base/java.lang.System.getProperty(System.java:833) > at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) > at DoPrivAccomplice.go(DoPrivAccomplice.java:30) > at DoPrivTest.main(DoPrivTest.java:29) > ] > exitValue = 1 > > java.lang.RuntimeException: 'user' found in stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) > at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr > > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr > > Looks like test is not ready for username `user`, which I use locally. ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" STDOUT: [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) [00:56:54.693] TRACE: Test string code points: [0x00e9] [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... [00:56:55.996] TRACE: exec: Done. Exit code: 0 [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... [00:56:56.188] TRACE: exec: Done. Exit code: 0 [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output [00:57:07.680] Command: jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrume nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files [00:57:07.680] Output: WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign [00:57:07.681] Returned: 0 [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). [00:57:07.746] Succeeded in building Windows Application Image package [00:57:07.748] TRACE: exec: Done. Exit code: 0 [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file [00:57:07.780] TRACE: Clearing PATH in environment [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... hello: Environment supports a display hello: Environment supports a desktop [0x0065] jpackage test application args.length: 1 e hello: Output file: [appOutput.txt] [00:57:09.302] TRACE: exec: Done. Exit code: 0 [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) [00:57:09.312] TRACE: Test string code points: [0x00e9] [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... [00:57:09.658] TRACE: exec: Done. Exit code: 0 [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... [00:57:09.667] TRACE: exec: Done. Exit code: 0 [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... [00:57:09.670] jpackage argument list: [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output [00:57:18.770] Command: jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrume nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files [00:57:18.770] Output: WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign [00:57:18.770] Returned: 0 [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). [00:57:18.787] Succeeded in building Windows Application Image package [00:57:18.788] TRACE: exec: Done. Exit code: 0 [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file [00:57:18.808] TRACE: Clearing PATH in environment [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... hello: Environment supports a display hello: Environment supports a desktop [0x0065] jpackage test application args.length: 1 e hello: Output file: [appOutput.txt] [00:57:20.327] TRACE: exec: Done. Exit code: 0 [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 [00:57:20.332] [==========] 2 tests ran [00:57:20.333] [ PASSED ] 0 tests [00:57:20.334] [ FAILED ] 2 tests, listed below [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] [00:57:20.336] 2 FAILED TESTS STDERR: java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file at jdk.jpackage.test.TKit.error(TKit.java:293) at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.TKit.runTests(TKit.java:136) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file at jdk.jpackage.test.TKit.error(TKit.java:293) at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.TKit.runTests(TKit.java:136) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.RuntimeException: 2 FAILED TESTS at jdk.jpackage.test.Main.reportSummary(Main.java:130) at jdk.jpackage.test.Main.runTests(Main.java:90) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) ... 8 more JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS Oh. This one is tricky. Will investigate later. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From darcy at openjdk.java.net Fri Feb 12 22:23:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:23:41 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:17:48 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 135: > >> 133: * into equivalence classes; all the members of an >> 134: * equivalence class are equal to each other. The equal objects >> 135: * are substitutable for each other, at least for some purposes. > > Since the preceding sentence mentions the members of an equivalence class, it might read better to say "Members are substitutable..." or possibly "Members of an equivalence class are substitutable...." Phrasing updated to: "Members of an equivalence class are substitutable for each other, at least for some purposes." ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Fri Feb 12 22:31:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:31:42 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:22:18 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos in javadoc tags found during review. > > src/java.base/share/classes/java/lang/Object.java line 236: > >> 234: * be a concise but informative representation that is easy for a >> 235: * person to read. >> 236: * It is recommended that all subclasses override this method. > > Do we want to have a general note here or somewhere that the exact format of the result of `toString()` is generally not stable, and that it is subject to change without notice? Added "The string output is not necessary stable over time." The particulars of the toString contract of a given class will depend on the class of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Fri Feb 12 22:35:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:35:42 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Thu, 11 Feb 2021 04:44:08 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 97: >> >>> 95: * contrast, the {@link equals equals} method requires both the >>> 96: * numerical value and representation to be the same for equality to >>> 97: * hold. >> >> Note, discussing "representation" is ok here since the context is discussing the representation of BigDecimal (in contrast to the text in Comparable). > > It might be reasonable to add a bit of rationale here and give an example. I think the reason that members of the same cohort might not be considered `equals()` to one another is that they are not substitutable. For example, consider 2.0 and 2.00. They are members of the same cohort, because > > new BigDecimal("2.0").compareTo(new BigDecimal("2.00")) == 0 > > is true. However, > > new BigDecimal("2.0").equals(new BigDecimal("2.00")) > > is false. They aren't considered `equals()` because they aren't substitutable, since using them in an arithmetic expression can give different results. For example: > > new BigDecimal("2.0").divide(new BigDecimal(3), RoundingMode.HALF_UP) > ==> 0.7 > > new BigDecimal("2.00").divide(new BigDecimal(3), RoundingMode.HALF_UP) > ==> 0.67 > > I think that's the right rationale, and a reasonable example to illustrate it. Edit to taste. I think it would be good to have material like this, though, because people's immediate reaction to BD being inconsistent with equals is "well that's wrong." Well, no, it's right, and I think this is the reason. Added example using scale and unscaledValue. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Fri Feb 12 22:42:56 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:42:56 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v5] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: <_px4gzUUo05JRGIv2WL5OlaxGmCmvGxS6rnehta4Xdo=.956394bd-f351-4b04-9981-5fe544f17e60@github.com> > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/a7f1b28b..41102f52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=03-04 Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From rriggs at openjdk.java.net Fri Feb 12 22:42:57 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Feb 2021 22:42:57 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 22:28:33 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Object.java line 236: >> >>> 234: * be a concise but informative representation that is easy for a >>> 235: * person to read. >>> 236: * It is recommended that all subclasses override this method. >> >> Do we want to have a general note here or somewhere that the exact format of the result of `toString()` is generally not stable, and that it is subject to change without notice? > > Added "The string output is not necessary stable over time." The particulars of the toString contract of a given class will depend on the class of course. Perhaps "necessary" -> "necessarily" ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From mchung at openjdk.java.net Fri Feb 12 22:51:46 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 12 Feb 2021 22:51:46 GMT Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3] In-Reply-To: References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com> Message-ID: On Fri, 12 Feb 2021 02:10:02 GMT, Coleen Phillimore wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Consolidate verifyClassname and verifyFixClassname > > This more limited cleanup looks good. This patch changes `JVM_FindLoadedClass` interface to only accept a binary name. It used to accept both a binary name and internal form. Most, if not all, JVM entry points take the name of internal name. So this change makes this JVM entry point inconsistent with others. Looking closer each API that involves `fixClassName` or `verifyXXXClassName`, the JVM entry points called expects the internal form except `JVM_FindLoadedClass` (see details below). I think a better change is to change the native `JVM_FindLoadedClass` to accept the internal form only and have `findLoadedClass0` method to detect if the name contains '/' or '['. ClassLoader API does not allow loading of an array type whereas `Class::forName` allows to find an array type. Perhaps `verifyFixClassName` should be renamed like `binaryNameToInternalForm`. I think we don't need `fixClassname`? ClassLoader::defineClass - `preDefineClass` checks the name and throws if it contains '/' or '[' - no name check in `JVM_DefineClassWithSource` and `JVM_LookupDefineClass` which expects the name is of internal form native Class::forName0 - converts the binary name to internal form (i.e. replace '.' with '/') - throw if the name contains '/' - no explicit name check in `JVM_FindClassFromCaller` ClassLoader::loadClass - calls native `findLoadedClass0` that calls `JVM_FindLoadedClass` which accepts binary form and converts '.' to '/' but the current implementation accepts both binary name and internal form - calls `native findBootstrapClass` which converts '.' to '/' and pass the internal form to `JVM_FindBootstrapClass`. It'd be helpful to document the internal APIs and JVM entry points clearly what it expects for example binary name vs internal form and where it does the validation e.g. Class::forName0 allows array type and native library methods do the name validation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2378 From darcy at openjdk.java.net Fri Feb 12 22:52:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:52:06 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/41102f52..03f01e65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Fri Feb 12 22:52:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 12 Feb 2021 22:52:06 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 22:39:55 GMT, Roger Riggs wrote: >> Added "The string output is not necessary stable over time." The particulars of the toString contract of a given class will depend on the class of course. > > Perhaps "necessary" -> "necessarily" Good catch Roger; will change to "The string output is not necessarily stable over time or across JVM invocations." The latter clause will more explicitly handle cases like "myEnumConstant.toString() gave different answers when I ran the program multiple times," a bug that has been submitted as closed as not-a-bug repeated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From smarks at openjdk.java.net Fri Feb 12 23:33:44 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 12 Feb 2021 23:33:44 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 22:52:06 GMT, Joe Darcy wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. Marked as reviewed by smarks (Reviewer). src/java.base/share/classes/java/math/BigDecimal.java line 99: > 97: * hold. The results of methods like {@link scale} and {@link > 98: * unscaledValue} will differ for numerically equal values with > 99: * different representations. While this text is correct and reasonable, it doesn't really explain _why_ equals() considers the representation. One might assume incorrectly that the representation is internal only and doesn't affect computations. Of course it does affect computations, which is why I suggested the example. Maybe the example doesn't belong right here, in which case it's reasonable for this change to proceed. I think it would be good to put an example _somewhere_ of non-substitutability of numerical values with different representations. Maybe we could handle that separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From smarks at openjdk.java.net Fri Feb 12 23:33:44 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 12 Feb 2021 23:33:44 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v3] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 22:12:30 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Comparable.java line 90: >> >>> 88: * of the {@code equals} method and the equivalence classes defined by >>> 89: * the quotient of the {@code compareTo} method are the same. >>> 90: * >> >> I think in both cases it should be "the equivalence class defined by...." That is, "equivalence class" should be singular. But there are two of them, so the sentence still properly concludes "... are the same." > > An equivalence relation defines a *set* of equivalence classes which partition the objects the relation operates on. For example, the "same signum value" equivalence relation on integers has three equivalence classes : > 1) negative nonzero numbers (corresponding to signum == -1) > 2) zero (corresponding to signum = 0) > 3) positive nonzero numbers (corresponding to signum ==1) OK, got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From bpb at openjdk.java.net Fri Feb 12 23:43:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 23:43:40 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: Message-ID: <9RViNaCDKas4SzjgeugVHfV_l6M8E-RgJa5JItfJLrE=.e10fc048-5492-479b-b938-4226a18e1e84@github.com> On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? > > As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. > > Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. > > Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. > > Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. > > Given the nature of this issue, I haven't added any jtreg test for this change. I think you can go ahead and integrate this now. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2326 From bpb at openjdk.java.net Fri Feb 12 23:43:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 23:43:40 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: <0oEEm3IA1yrfN6hjjUDW9bYUdB_Pp2AWhO3a32jLF2E=.110c0b17-bf8d-4569-9b62-7ff6af1dcb26@github.com> <0o9OBXiPLjgDSCNycyOCB-mU39kl3nz22FOxDIRr3jA=.30c736ec-fd0e-4028-9742-8f7d102a418b@github.com> Message-ID: On Fri, 12 Feb 2021 03:34:54 GMT, Jaikiran Pai wrote: >> Did you run this through the usual CI tests in all tiers? > >> Did you run this through the usual CI tests in all tiers? > > Hello Brian, > > Do you mean other than the ones that have been automatically run and passed in the GitHub actions against this PR? I don't have a Windows box, but if there's some specific tests you want me to run locally, please do let me know and I'll run them. > On Feb 11, 2021, at 7:35 PM, Jaikiran wrote: > > Did you run this through the usual CI tests in all tiers? > > Hello Brian, > > Do you mean other than the ones that have been automatically run and passed in the GitHub actions against this PR? I don't have a Windows box, but if there's some specific tests you want me to run locally, please do let me know and I'll run them. > I ran this through our internal CI tests and saw no problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From bpb at openjdk.java.net Fri Feb 12 23:51:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Feb 2021 23:51:40 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 16:04:02 GMT, stefan-zobel wrote: >> I haven't written the class Preconditions.java, this question should probably go to the authors . >> I found the String.format syntax a bit unusual, should this be rewritten ? > > AFAIK, Preconditions was introduced in https://bugs.openjdk.java.net/browse/JDK-8155794 It looks like java/util/Objects/CheckIndex should adequately cover this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From joehw at openjdk.java.net Sat Feb 13 00:22:51 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 13 Feb 2021 00:22:51 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer Message-ID: Adds a property similar to 'isStandalone' in JDK-8249867. Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. ------------- Commit messages: - JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer Changes: https://git.openjdk.java.net/jdk/pull/2559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260858 Stats: 243 lines in 7 files changed: 167 ins; 4 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/2559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2559/head:pull/2559 PR: https://git.openjdk.java.net/jdk/pull/2559 From jpai at openjdk.java.net Sat Feb 13 02:17:41 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 13 Feb 2021 02:17:41 GMT Subject: RFR: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: <9RViNaCDKas4SzjgeugVHfV_l6M8E-RgJa5JItfJLrE=.e10fc048-5492-479b-b938-4226a18e1e84@github.com> References: <9RViNaCDKas4SzjgeugVHfV_l6M8E-RgJa5JItfJLrE=.e10fc048-5492-479b-b938-4226a18e1e84@github.com> Message-ID: On Fri, 12 Feb 2021 23:40:51 GMT, Brian Burkhalter wrote: >> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? >> >> As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. >> >> Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. >> >> Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. >> >> Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. >> >> Given the nature of this issue, I haven't added any jtreg test for this change. > > I think you can go ahead and integrate this now. Thank you Brian for the review and help in testing the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From jpai at openjdk.java.net Sat Feb 13 02:17:41 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 13 Feb 2021 02:17:41 GMT Subject: Integrated: 8260401: StackOverflowError on open WindowsPreferences In-Reply-To: References: Message-ID: On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8260401? > > As noted in that issue, when the constructor of `java.util.prefs.WindowsPreferences` runs into an error while dealing with the Windows registry, it logs a warning message. The message construction calls `rootNativeHandle()` (on the same instance of `WindowsPreferences` that's being constructed) which then ultimately ends up calling the constructor of `WindowsPreferences` which then again runs into the Windows registry error and attempts to log a message and this whole cycle repeats indefinitely leading to that `StackOverFlowError`. > > Based on my limited knowledge of the code in that constructor and analyzing that code a bit, it's my understanding (and also the input provided by the reporter of the bug) that the log message should actually be using the `rootNativeHandle` parameter that is passed to this constructor instead of invoking the `rootNativeHandle()` method. The commit in this PR does this change to use the passed `rootNativeHandle` in the log message. > > Furthermore, there's another constructor in this class which does a similar thing and potentially can run into the same error as this one. I've changed that constructor too, to avoid the call to `rootNativeHandle()` method in that log message. Reading the log message that's being generated there, it's my understanding that this change shouldn't cause any inaccuracy in what's being logged and in fact, I think it's now more precise about which handle returned the error code. > > Finally, this log message creation, in both the constructors, also calls `windowsAbsolutePath()` and `byteArrayToString()` methods. The `byteArrayToString()` is a static method and a call to it doesn't lead back to the constructor again. The `windowsAbsolutePath()` is a instance method and although it does use a instance variable `absolutePath`, that instance variable is already initialized appropriately by the time this `windowsAbsolutePath()` gets called in the log message. Also, the `windowsAbsolutePath()` call doesn't lead back to the constructor of the `WindowsPreferences` so it doesn't pose the same issue as a call to `rootNativeHandle()`. > > Given the nature of this issue, I haven't added any jtreg test for this change. This pull request has now been integrated. Changeset: 849390a1 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/849390a1 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8260401: StackOverflowError on open WindowsPreferences Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2326 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 10:23:43 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 10:23:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov wrote: >> ## java/security/AccessController/DoPrivAccompliceTest.java >> >> make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java" >> >> STDOUT: >> Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> >> Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> >> Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar >> Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\ windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] >> [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712 >> [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712 >> [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712 >> Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log' >> [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712 >> [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712 >> Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar >> Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\ windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ] >> [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560 >> [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560 >> Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log' >> [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560 >> [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560 >> STDERR: >> stdout: []; >> stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read") >> at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) >> at java.base/java.security.AccessController.checkPermission(AccessController.java:1036) >> at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408) >> at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152) >> at java.base/java.lang.System.getProperty(System.java:833) >> at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) >> at DoPrivAccomplice.go(DoPrivAccomplice.java:30) >> at DoPrivTest.main(DoPrivTest.java:29) >> ] >> exitValue = 1 >> >> java.lang.RuntimeException: 'user' found in stderr >> >> at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256) >> at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> >> JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr >> >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr >> >> Looks like test is not ready for username `user`, which I use locally. > > ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java > > make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" > > STDOUT: > [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... > [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] > [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) > [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) > [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) > [00:56:54.693] TRACE: Test string code points: [0x00e9] > [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... > [00:56:55.996] TRACE: exec: Done. Exit code: 0 > [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code > [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... > [00:56:56.188] TRACE: exec: Done. Exit code: 0 > [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code > [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... > [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output > [00:57:07.680] Command: > jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instru ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files > [00:57:07.680] Output: > WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign > > [00:57:07.681] Returned: 0 > > [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). > [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". > [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). > [00:57:07.746] Succeeded in building Windows Application Image package > [00:57:07.748] TRACE: exec: Done. Exit code: 0 > [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code > [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package > [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) > [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists > [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file > [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable > [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists > [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file > [00:57:07.780] TRACE: Clearing PATH in environment > [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... > hello: Environment supports a display > hello: Environment supports a desktop > [0x0065] > jpackage test application > args.length: 1 > e > hello: Output file: [appOutput.txt] > [00:57:09.302] TRACE: exec: Done. Exit code: 0 > [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code > [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists > [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file > [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) > [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) > [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 > [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) > [00:57:09.312] TRACE: Test string code points: [0x00e9] > [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... > [00:57:09.658] TRACE: exec: Done. Exit code: 0 > [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code > [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... > [00:57:09.667] TRACE: exec: Done. Exit code: 0 > [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code > [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... > [00:57:09.670] > jpackage argument list: > [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] > > [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output > [00:57:18.770] Command: > jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instru ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files > [00:57:18.770] Output: > WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign > > [00:57:18.770] Returned: 0 > > [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). > [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". > [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). > [00:57:18.787] Succeeded in building Windows Application Image package > [00:57:18.788] TRACE: exec: Done. Exit code: 0 > [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code > [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package > [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) > [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists > [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file > [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable > [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists > [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file > [00:57:18.808] TRACE: Clearing PATH in environment > [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... > hello: Environment supports a display > hello: Environment supports a desktop > [0x0065] > jpackage test application > args.length: 1 > e > hello: Output file: [appOutput.txt] > [00:57:20.327] TRACE: exec: Done. Exit code: 0 > [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code > [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists > [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file > [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) > [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) > [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 > [00:57:20.332] [==========] 2 tests ran > [00:57:20.333] [ PASSED ] 0 tests > [00:57:20.334] [ FAILED ] 2 tests, listed below > [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] > [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] > [00:57:20.336] 2 FAILED TESTS > STDERR: > java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file > at jdk.jpackage.test.TKit.error(TKit.java:293) > at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) > at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) > at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) > at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) > at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.TKit.runTests(TKit.java:136) > at jdk.jpackage.test.Main.runTests(Main.java:79) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file > at jdk.jpackage.test.TKit.error(TKit.java:293) > at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) > at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) > at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) > at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) > at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) > at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) > at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) > at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) > at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.TKit.runTests(TKit.java:136) > at jdk.jpackage.test.Main.runTests(Main.java:79) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) > at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) > at jdk.jpackage.test.Main.main(Main.java:75) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: 2 FAILED TESTS > at jdk.jpackage.test.Main.reportSummary(Main.java:130) > at jdk.jpackage.test.Main.runTests(Main.java:90) > at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) > at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) > ... 8 more > > JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS > > Oh. This one is tricky. Will investigate later. This fours tests pass without problems, when I run them separately. ## sun/security/tools/jarsigner/TimestampCheck.java ## sun/security/tools/keytool/DefaultOptions.java ## sanity/client/SwingSet/src/ColorChooserDemoTest.java ## sanity/client/SwingSet/src/SwingSet2DemoTest.java make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" Building target 'test' in configuration 'windows-x86_64-server-release' Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' Passed: sun/security/tools/jarsigner/TimestampCheck.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' Passed: sun/security/tools/keytool/DefaultOptions.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java Test results: passed: 1 Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java 1 1 0 0 jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java 1 1 0 0 jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java 1 1 0 0 jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java 1 1 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'windows-x86_64-server-release' ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 10:59:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 10:59:38 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov wrote: >> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java >> >> make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java" >> >> STDOUT: >> [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]... >> [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)] >> [00:56:54.682] Create: UnicodeArgsTest.test8246042(true) >> [00:56:54.684] Create: UnicodeArgsTest.test8246042(false) >> [00:56:54.688] [ RUN ] UnicodeArgsTest.test8246042(false) >> [00:56:54.693] TRACE: Test string code points: [0x00e9] >> [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... >> [00:56:55.996] TRACE: exec: Done. Exit code: 0 >> [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code >> [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)... >> [00:56:56.188] TRACE: exec: Done. Exit code: 0 >> [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code >> [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)... >> [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output >> [00:57:07.680] Command: >> jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instr ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files >> [00:57:07.680] Output: >> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign >> >> [00:57:07.681] Returned: 0 >> >> [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). >> [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224". >> [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). >> [00:57:07.746] Succeeded in building Windows Application Image package >> [00:57:07.748] TRACE: exec: Done. Exit code: 0 >> [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code >> [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package >> [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml) >> [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists >> [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file >> [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable >> [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists >> [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file >> [00:57:07.780] TRACE: Clearing PATH in environment >> [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]... >> hello: Environment supports a display >> hello: Environment supports a desktop >> [0x0065] >> jpackage test application >> args.length: 1 >> e >> hello: Output file: [appOutput.txt] >> [00:57:09.302] TRACE: exec: Done. Exit code: 0 >> [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code >> [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists >> [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file >> [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application) >> [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1) >> [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> [00:57:09.308] [ FAILED ] UnicodeArgsTest.test8246042(false); checks=15 >> [00:57:09.310] [ RUN ] UnicodeArgsTest.test8246042(true) >> [00:57:09.312] TRACE: Test string code points: [0x00e9] >> [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)... >> [00:57:09.658] TRACE: exec: Done. Exit code: 0 >> [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code >> [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)... >> [00:57:09.667] TRACE: exec: Done. Exit code: 0 >> [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code >> [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)... >> [00:57:09.670] >> jpackage argument list: >> [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose] >> >> [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output >> [00:57:18.770] Command: >> jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instr ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files >> [00:57:18.770] Output: >> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign >> >> [00:57:18.770] Returned: 0 >> >> [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize). >> [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275". >> [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize). >> [00:57:18.787] Succeeded in building Windows Application Image package >> [00:57:18.788] TRACE: exec: Done. Exit code: 0 >> [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code >> [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package >> [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml) >> [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists >> [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file >> [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable >> [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists >> [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file >> [00:57:18.808] TRACE: Clearing PATH in environment >> [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]... >> hello: Environment supports a display >> hello: Environment supports a desktop >> [0x0065] >> jpackage test application >> args.length: 1 >> e >> hello: Output file: [appOutput.txt] >> [00:57:20.327] TRACE: exec: Done. Exit code: 0 >> [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code >> [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists >> [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file >> [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application) >> [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1) >> [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> [00:57:20.331] [ FAILED ] UnicodeArgsTest.test8246042(true); checks=15 >> [00:57:20.332] [==========] 2 tests ran >> [00:57:20.333] [ PASSED ] 0 tests >> [00:57:20.334] [ FAILED ] 2 tests, listed below >> [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070] >> [00:57:20.335] [ FAILED ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11] >> [00:57:20.336] 2 FAILED TESTS >> STDERR: >> java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file >> at jdk.jpackage.test.TKit.error(TKit.java:293) >> at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) >> at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) >> at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) >> at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) >> at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) >> at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.TKit.runTests(TKit.java:136) >> at jdk.jpackage.test.Main.runTests(Main.java:79) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file >> at jdk.jpackage.test.TKit.error(TKit.java:293) >> at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) >> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) >> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) >> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) >> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) >> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) >> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) >> at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225) >> at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405) >> at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417) >> at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319) >> at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155) >> at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140) >> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) >> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) >> at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.TKit.runTests(TKit.java:136) >> at jdk.jpackage.test.Main.runTests(Main.java:79) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107) >> at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123) >> at jdk.jpackage.test.Main.main(Main.java:75) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.RuntimeException: 2 FAILED TESTS >> at jdk.jpackage.test.Main.reportSummary(Main.java:130) >> at jdk.jpackage.test.Main.runTests(Main.java:90) >> at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) >> at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) >> ... 8 more >> >> JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS >> >> Oh. This one is tricky. Will investigate later. > > This fours tests pass without problems, when I run them separately. > > ## sun/security/tools/jarsigner/TimestampCheck.java > ## sun/security/tools/keytool/DefaultOptions.java > ## sanity/client/SwingSet/src/ColorChooserDemoTest.java > ## sanity/client/SwingSet/src/SwingSet2DemoTest.java > > make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" > > Building target 'test' in configuration 'windows-x86_64-server-release' > Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: > * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java > * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java > * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java > * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java > > Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' > Passed: sun/security/tools/jarsigner/TimestampCheck.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java > Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java > > Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' > Passed: sun/security/tools/keytool/DefaultOptions.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java > Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java > > Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' > Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java > Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java > > Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' > Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java > Test results: passed: 1 > Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html > Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java > Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' > Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java > 1 1 0 0 > jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java > 1 1 0 0 > jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java > 1 1 0 0 > jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java > 1 1 0 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration 'windows-x86_64-server-release' ## jdk/jshell/ToolBasicTest.java make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" STDOUT: [TestNG] Running: jdk/jshell/ToolBasicTest.java config ReplToolTesting.setUp(): success test ToolBasicTest.elideStartUpFromList(): success config ReplToolTesting.setUp(): success test ToolBasicTest.elideStartUpFromSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.test8142447(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testAddExports(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadClasspath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadModulePath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testBadSourceJarClasspath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathDirectory(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathJar(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testClasspathUserHomeExpansion(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testConstrainedUpdates(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testCtrlD(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testEnvInStartUp(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackNegative(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackNormal(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testFeedbackSilent(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testHistoryReference(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testIndent(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testInterrupt(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testLoadingFromArgs(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testModulePath(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testModulePathUserHomeExpansion(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpen(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenFileOverHttp(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenLocalFileUrl(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testOpenResource(): failure java.lang.AssertionError: user output: printf("%4.2f", Math.PI). expected [3.14] but found [3,14] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:496) at org.testng.Assert.assertEquals(Assert.java:125) at org.testng.Assert.assertEquals(Assert.java:178) at ReplToolTesting.assertOutput(ReplToolTesting.java:529) at ReplToolTesting.assertCommand(ReplToolTesting.java:513) at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) at java.base/java.io.PrintStream.write(PrintStream.java:536) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) at ReplToolTesting.testRawRun(ReplToolTesting.java:313) at ReplToolTesting.testRaw(ReplToolTesting.java:296) at ReplToolTesting.test(ReplToolTesting.java:249) at ReplToolTesting.test(ReplToolTesting.java:233) at ReplToolTesting.test(ReplToolTesting.java:229) at ReplToolTesting.test(ReplToolTesting.java:225) at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) config ReplToolTesting.setUp(): success test ToolBasicTest.testRedeclareVariableNoInit(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRemoteExit(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRerun(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testRerunIdRange(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testReset(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartRetain(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartSave(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStartupFileOption(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testStop(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testVarsWithNotActive(): success config ReplToolTesting.setUp(): success test ToolBasicTest.testWarningUnchecked(): success =============================================== jdk/jshell/ToolBasicTest.java Total tests run: 38, Failures: 1, Skips: 0 =============================================== STDERR: java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) at ReplToolTesting.testRawRun(ReplToolTesting.java:313) at ReplToolTesting.testRaw(ReplToolTesting.java:296) at ReplToolTesting.test(ReplToolTesting.java:249) at ReplToolTesting.test(ReplToolTesting.java:233) at ReplToolTesting.test(ReplToolTesting.java:229) at ReplToolTesting.test(ReplToolTesting.java:225) at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) java.lang.Exception: failures: 1 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From turbanoff at gmail.com Sat Feb 13 14:29:02 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 13 Feb 2021 17:29:02 +0300 Subject: Thread safety of SunFontManager.platformFontMap Message-ID: Hello. I recently found suspicious field (with SpotBugs help) in class SunFontManager: static HashMap platformFontMap; This HashMap is accessed (read and write) in a method sun.font.SunFontManager#findFontFromPlatformMap. As I see there is no synchronization when this HashMap is accessed. This method can be called from client code with this simple stack trace: at sun.font.SunFontManager.findFontFromPlatformMap(SunFontManager.java:1508) at sun.font.SunFontManager.findFont2D(SunFontManager.java:2069) at java.awt.Font.getFont2D(Font.java:500) at java.awt.Font.getPSName(Font.java:1416) I wonder if this unsynchronized access is expected. Looks like it can break things when accessed from multiple threads simultaneously. Do I miss something? Is it done this way, because Font objects are supposed to be accessed from a single thread only? Andrey Turbanov From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 15:06:41 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 15:06:41 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/java/util/Random.java line 29: > 27: > 28: import java.io.*; > 29: import java.math.BigInteger; This import is not actually used ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 15:10:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 15:10:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 115: > 113: static final String BAD_BOUND = "bound must be positive"; > 114: static final String BAD_FLOATING_BOUND = "bound must be finite and positive"; > 115: static final String BAD_RANGE = "bound must be greater than origin"; Unused fields in Random class now can be cleaned up: `java.util.Random#BadRange`, `java.util.Random#BadSize` ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+741251+turbanoff at openjdk.java.net Sat Feb 13 21:34:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sat, 13 Feb 2021 21:34:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 16:02:03 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Added table of available algorithms. src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 149: > 147: */ > 148: public static void checkJumpDistance(double distance) { > 149: if (!(distance > 0.0 && distance < Float.POSITIVE_INFINITY I wounder if this usage of `Float.POSITIVE_INFINITY` intentional here? Looks a bit suspicious for comparison with `double` argument src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: > 1546: * @return a stream of (pseudo)randomly chosen {@code int} values > 1547: */ > 1548: Is `@Override` intentionally omitted? src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1943: > 1941: > 1942: // IllegalArgumentException messages > 1943: static final String BadLogDistance = "logDistance must be non-negative"; seems unused test/jdk/java/util/Random/RandomTestBsi1999.java line 227: > 225: static int checkRunStats(int[] stats) { > 226: int runFailure = 0; > 227: runFailure |= ((2267 <= stats[1]) || (stats[1] <= 2733)) ? 0 : 1; 1. confusing formatting. 2. This condition is always `true`. Looks like `&&` should be used instead of `||` ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From lancea at openjdk.java.net Sun Feb 14 15:21:41 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 14 Feb 2021 15:21:41 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 00:16:50 GMT, Joe Wang wrote: > Adds a property similar to 'isStandalone' in JDK-8249867. > > Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From naoto at openjdk.java.net Sun Feb 14 21:30:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sun, 14 Feb 2021 21:30:40 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 00:16:50 GMT, Joe Wang wrote: > Adds a property similar to 'isStandalone' in JDK-8249867. > > Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 107: > 105: + "\n" > 106: + ""; > 107: Could be better to use text blocks? ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From xliu at openjdk.java.net Mon Feb 15 09:26:56 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 15 Feb 2021 09:26:56 GMT Subject: RFR: 8261731: shallow copy the internal buffer of a scalar-replaced java.lang.String object Message-ID: There are 3 nodes involving in the construction of a java.lang.String object. 1. Allocate of itself, aka. alloc 2. AllocateArray of a byte array, which is value:byte[], aka. aa 3. ArrayCopyNode which copys in the contents of value, aka. ac Lemma When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`. Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well. It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a ?shallow copy? of the source of `ac`. It?s safe if C2 keeps a reference of the source oop for all safepoints. ------------- Commit messages: - fix regression for x86-32 - add a statistical counter for OptimizeTempArray. - [SIM-JVM-450] support deoptimization v2 - add a unit test for deoptimization - [SIM-JVM-450] support deoptimization part2 - enable OptimizeTempArray by default - Merge branch 'master' into optimize_substring - Revert "8260198: TypeInstPtr::dump2() emits multiple lines if Verbose is set" - Revert "add a new bucket afterea_late_inlines" - [SIM-JVM-450] support deoptimization - ... and 25 more: https://git.openjdk.java.net/jdk/compare/4619f372...fd9ca4b8 Changes: https://git.openjdk.java.net/jdk/pull/2570/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2570&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261731 Stats: 861 lines in 16 files changed: 844 ins; 2 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2570/head:pull/2570 PR: https://git.openjdk.java.net/jdk/pull/2570 From ewhelan at openjdk.java.net Mon Feb 15 10:44:56 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 15 Feb 2021 10:44:56 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows Message-ID: Hi, Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. This fix passes all testing. Kind regards, Evan ------------- Commit messages: - 8252883: AccessDeniedException caused by delayed file deletion on Windows Changes: https://git.openjdk.java.net/jdk/pull/2572/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252883 Stats: 131 lines in 2 files changed: 124 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From alanb at openjdk.java.net Mon Feb 15 11:49:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Feb 2021 11:49:38 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java >> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java >> >> make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" >> >> Building target 'test' in configuration 'windows-x86_64-server-release' >> Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: >> * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> >> Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Passed: sun/security/tools/jarsigner/TimestampCheck.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> >> Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Passed: sun/security/tools/keytool/DefaultOptions.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> 1 1 0 0 >> jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'windows-x86_64-server-release' > > ## jdk/jshell/ToolBasicTest.java > > make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" > > STDOUT: > [TestNG] Running: > jdk/jshell/ToolBasicTest.java > > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromList(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.test8142447(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testAddExports(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadSourceJarClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathDirectory(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathJar(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testConstrainedUpdates(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testCtrlD(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testEnvInStartUp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNegative(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNormal(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackSilent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testHistoryReference(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testIndent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testInterrupt(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testLoadingFromArgs(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpen(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenFileOverHttp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenLocalFileUrl(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenResource(): failure > java.lang.AssertionError: user output: printf("%4.2f", Math.PI). > expected [3.14] but found [3,14] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at ReplToolTesting.assertOutput(ReplToolTesting.java:529) > at ReplToolTesting.assertCommand(ReplToolTesting.java:513) > at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) > at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) > at java.base/java.io.PrintStream.write(PrintStream.java:536) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) > at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) > at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) > at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) > at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) > at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) > at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) > at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) > at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRedeclareVariableNoInit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRemoteExit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerun(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerunIdRange(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testReset(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartRetain(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartupFileOption(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStop(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testVarsWithNotActive(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testWarningUnchecked(): success > > =============================================== > jdk/jshell/ToolBasicTest.java > Total tests run: 38, Failures: 1, Skips: 0 > =============================================== > > STDERR: > java.io.EOFException > at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) > at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) > at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) > at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. @turbanoff Can you run the tests in the en_US locale? I suspect some of these tests can't run in all locales. Also can you check your environment to ensure the file paths for F: are consistent (I suspect you have a mix of f: and F: in the environment). ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From clanger at openjdk.java.net Mon Feb 15 13:18:41 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 15 Feb 2021 13:18:41 GMT Subject: RFR: 8253702: BigSur version number reported as 10.16, should be 11.nn [v3] In-Reply-To: References: Message-ID: <_H2Btml_mHwHd3PcvHKd1DL3p6RuoY1ozVt0-W5q-go=.a80d8db9-6e44-4df4-aaef-f39dd4393b51@github.com> On Thu, 11 Feb 2021 19:30:02 GMT, Kevin Rushforth wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set > > Looks good. Thanks for the fix! This is probably the best we can get without spawning an external process to e.g. call sw_vers to get the actual, non-compat version number. Unfortunately, the test java/lang/System/OsVersionTest.java will still fail on systems where the MacOS version has a patch number (>1), e.g. the current MacOS 11.2.1 - in line with Kevin's report about the behavior on an 11.0.1 system. I will open another ticket and propose a test update that relaxes the check in the test a little... ------------- PR: https://git.openjdk.java.net/jdk/pull/2530 From dfuchs at openjdk.java.net Mon Feb 15 13:22:43 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 15 Feb 2021 13:22:43 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 10:39:32 GMT, Evan Whelan wrote: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan src/java.logging/share/classes/java/util/logging/FileHandler.java line 39: > 37: import java.nio.channels.FileChannel; > 38: import java.nio.channels.OverlappingFileLockException; > 39: import java.nio.file.*; We avoid using the wildcard with imports in the JDK sources. Could you revert that change? src/java.logging/share/classes/java/util/logging/FileHandler.java line 517: > 515: continue; > 516: } > 517: else { nit: can you put the closing brace and the else on the same line? src/java.logging/share/classes/java/util/logging/FileHandler.java line 512: > 510: // Try again. If it doesn't work, then this will > 511: // eventually ensure that we increment "unique" and > 512: // use another file name. I believe this would be more clear if the comment was put inside the if statement, just before continue. It might be good to add some words about what might be causing the AccessDeniedException as well... Maybe something like: } catch (AccessDeniedException ade) { // This can be either a temporary, or a more permanent issue. // The lock file might be still pending deletion from a previous run // (temporary), or the parent directory might not be accessible, etc... // If we can write to the current directory, and this is a regular file, // let's try again. if (Files.isRegularFile(lockFilePath, LinkOption.NOFOLLOW_LINKS) && isParentWritable(lockFilePath)) { // Try again. If it doesn't work, then this will // eventually ensure that we increment "unique" and // use another file name. continue; } else { throw ade; // no need to retry } ... test/jdk/java/util/logging/FileHandlerAccessTest.java line 47: > 45: if (!(args.length == 2 || args.length == 1)) { > 46: System.out.println("Usage error: expects java FileHandlerAccessTest [process/thread] "); > 47: System.exit(1); We usually avoid `System.exit()` in tests. `return` should be enough. test/jdk/java/util/logging/FileHandlerAccessTest.java line 113: > 111: } > 112: } > 113: } Please add a newline at the end of the file. test/jdk/java/util/logging/FileHandlerAccessTest.java line 93: > 91: bufferedReader = new BufferedReader(new InputStreamReader(childProcess.getInputStream())); > 92: String line; > 93: while((line = bufferedReader.readLine()) != null) { space missing after `while` test/jdk/java/util/logging/FileHandlerAccessTest.java line 98: > 96: childProcess.waitFor(); > 97: } > 98: catch(Exception e) { space missing after `catch` test/jdk/java/util/logging/FileHandlerAccessTest.java line 106: > 104: } > 105: if (bufferedReader != null){ > 106: try{ space missing after `try` test/jdk/java/util/logging/FileHandlerAccessTest.java line 109: > 107: bufferedReader.close(); > 108: } > 109: catch(Exception ignored){} space missing after `catch` test/jdk/java/util/logging/FileHandlerAccessTest.java line 101: > 99: e.printStackTrace(); > 100: } > 101: finally { I would prefer if `catch` and `finally` where on the same line than the preceding closing brace: try { ... } catch (...) { ... } finally { ... } test/jdk/java/util/logging/FileHandlerAccessTest.java line 75: > 73: } > 74: catch(Exception e) { > 75: e.printStackTrace(); If you only print exceptions, when does the test fail? test/jdk/java/util/logging/FileHandlerAccessTest.java line 99: > 97: } > 98: catch(Exception e) { > 99: e.printStackTrace(); Same remark here: should this make the test fail? ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From clanger at openjdk.java.net Mon Feb 15 13:32:53 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 15 Feb 2021 13:32:53 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 Message-ID: After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. java.lang.Error: 11.2 != 11.2.1 This is a proposal to relax the test and throw a SkippedException in such cases. ------------- Commit messages: - JDK-8261753 Changes: https://git.openjdk.java.net/jdk/pull/2576/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261753 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2576/head:pull/2576 PR: https://git.openjdk.java.net/jdk/pull/2576 From clanger at openjdk.java.net Mon Feb 15 13:43:38 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 15 Feb 2021 13:43:38 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 13:27:36 GMT, Christoph Langer wrote: > After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. > > java.lang.Error: 11.2 != 11.2.1 > > This is a proposal to relax the test and throw a SkippedException in such cases. Throwing a SkippedException upon the special failure condition is just one possible suggestion. Alternatively we can also allow this as success condition. I'm also wondering whether we should run this test with the various possibilities for SYSTEM_VERSION_COMPAT settings. All under the assumption that we can't figure out the patch version of the macOS we run on. Thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/2576 From loikeseke at gmail.com Mon Feb 15 13:59:42 2021 From: loikeseke at gmail.com (=?UTF-8?Q?Lo=C3=AFc_MATHIEU?=) Date: Mon, 15 Feb 2021 14:59:42 +0100 Subject: System.getEnv(String name, String def) Message-ID: Hello, I wonder if there has already been some discussion to provide a System.getEnv(String name, String def) method that allows to return a default value in case the env variable didn't exist. When using system properties instead of env variable, we do have a System.getProperty(String key, String def) variant. Stating the JavaDoc of System.getEnv(): *System properties and environment variables are both conceptually mappings between names and values* So if system properties and environment variables are similar concepts, they should provide the same functionalities right ? This would be very convenient as more and more people rely on environment variables these days to configure their applications. Regards, Lo?c From forax at univ-mlv.fr Mon Feb 15 14:09:20 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 15 Feb 2021 15:09:20 +0100 (CET) Subject: System.getEnv(String name, String def) In-Reply-To: References: Message-ID: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> Hi Loic, You can use Optional.OfNullable() which is a kind of the general bridge between the nullable world and the non-nullable one. var fooOptional = Optional.ofNullable(System.getenv("FOO")); var fooValue = fooOptional.orElse(defaultValue); regards, R?mi Forax ----- Mail original ----- > De: "Lo?c MATHIEU" > ?: "core-libs-dev" > Envoy?: Lundi 15 F?vrier 2021 14:59:42 > Objet: System.getEnv(String name, String def) > Hello, > > I wonder if there has already been some discussion to provide > a System.getEnv(String name, String def) method that allows to return a > default value in case the env variable didn't exist. > > When using system properties instead of env variable, we do have a > System.getProperty(String key, String def) variant. > > Stating the JavaDoc of System.getEnv(): > *System properties and environment variables are both conceptually mappings > between names and values* > > So if system properties and environment variables are similar concepts, > they should provide the same functionalities right ? > > This would be very convenient as more and more people rely on > environment variables these days to configure their applications. > > Regards, > > Lo?c From rriggs at openjdk.java.net Mon Feb 15 14:09:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 15 Feb 2021 14:09:41 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 13:40:26 GMT, Christoph Langer wrote: >> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. >> >> java.lang.Error: 11.2 != 11.2.1 >> >> This is a proposal to relax the test and throw a SkippedException in such cases. > > Throwing a SkippedException upon the special failure condition is just one possible suggestion. Alternatively we can also allow this as success condition. > I'm also wondering whether we should run this test with the various possibilities for SYSTEM_VERSION_COMPAT settings. > > All under the assumption that we can't figure out the patch version of the macOS we run on. > > Thoughts? Given the lack of veracity from the os... Perhaps check that `swVersion.startsWith(osVersion) == true` (if the whole string doesn't match). I'm hopeful that when JDK 17 is released the toolchain has been upgraded and this patch won't be necessary. But if someone suggests backporting it, then a more through testing is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2576 From roger.riggs at oracle.com Mon Feb 15 14:13:05 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 15 Feb 2021 09:13:05 -0500 Subject: System.getEnv(String name, String def) In-Reply-To: References: Message-ID: <92f9a69d-cd9c-aa0a-b253-cdc2eb4a56b3@oracle.com> Hi, An alternative to a new API is to use the general purpose java.util.Objects.requireNonNull(T,T); Objects.requireNonNullElse(System.getEnv(String key), "n/a")); But a defaulting overload is straightforward. Regard, Roger On 2/15/21 8:59 AM, Lo?c MATHIEU wrote: > Hello, > > I wonder if there has already been some discussion to provide > a System.getEnv(String name, String def) method that allows to return a > default value in case the env variable didn't exist. > > When using system properties instead of env variable, we do have a > System.getProperty(String key, String def) variant. > > Stating the JavaDoc of System.getEnv(): > *System properties and environment variables are both conceptually mappings > between names and values* > > So if system properties and environment variables are similar concepts, > they should provide the same functionalities right ? > > This would be very convenient as more and more people rely on > environment variables these days to configure their applications. > > Regards, > > Lo?c From clanger at openjdk.java.net Mon Feb 15 14:39:38 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 15 Feb 2021 14:39:38 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 14:06:31 GMT, Roger Riggs wrote: > Given the lack of veracity from the os... > Perhaps check that `swVersion.startsWith(osVersion) == true` (if the whole string doesn't match). > > I'm hopeful that when JDK 17 is released the toolchain has been upgraded and this patch won't be necessary. > But if someone suggests backporting it, then a more through testing is needed. the .startsWith is a good suggestion which simplifies the code. I'll change this. As for the patch I think it will be necessary for a while. I for one want to backport it to JDK11 sine it hits there, too. And even if for JDK 17 we decide to build with a newer toolchain older toolchains might still be supported ------------- PR: https://git.openjdk.java.net/jdk/pull/2576 From redestad at openjdk.java.net Mon Feb 15 14:55:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Feb 2021 14:55:46 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad wrote: > This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. > > - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. > - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting > - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. > > Testing: tier1-3 On the best-case microbenchmark (the byte stream is all ASCII), speed-ups are quite telling: Before: Benchmark (charsetName) (length) Mode Cnt Score Error Units ByteStreamDecoder.readStringReader US-ASCII 256 avgt 10 2085.399 ? 66.522 ns/op ByteStreamDecoder.readStringReader US-ASCII 4096 avgt 10 12466.702 ? 747.116 ns/op ByteStreamDecoder.readStringReader US-ASCII 25000 avgt 10 123508.987 ? 3583.345 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 256 avgt 10 1894.185 ? 51.772 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 4096 avgt 10 8117.404 ? 594.708 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 25000 avgt 10 99409.792 ? 28308.936 ns/op ByteStreamDecoder.readStringReader UTF-8 256 avgt 10 2090.337 ? 56.500 ns/op ByteStreamDecoder.readStringReader UTF-8 4096 avgt 10 11698.221 ? 898.910 ns/op ByteStreamDecoder.readStringReader UTF-8 25000 avgt 10 66568.987 ? 4204.361 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 256 avgt 10 3061.130 ? 120.132 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 4096 avgt 10 24623.494 ? 1916.362 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 25000 avgt 10 139138.140 ? 7109.636 ns/op ByteStreamDecoder.readStringReader MS932 256 avgt 10 2612.535 ? 98.638 ns/op ByteStreamDecoder.readStringReader MS932 4096 avgt 10 18843.438 ? 1767.822 ns/op ByteStreamDecoder.readStringReader MS932 25000 avgt 10 119923.997 ? 18560.065 ns/op After: Benchmark (charsetName) (length) Mode Cnt Score Error Units ByteStreamDecoder.readStringReader US-ASCII 256 avgt 10 1556.588 ? 37.083 ns/op ByteStreamDecoder.readStringReader US-ASCII 4096 avgt 10 3290.627 ? 125.327 ns/op ByteStreamDecoder.readStringReader US-ASCII 25000 avgt 10 13118.794 ? 597.086 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 256 avgt 10 1525.460 ? 36.510 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 4096 avgt 10 3051.887 ? 113.036 ns/op ByteStreamDecoder.readStringReader ISO-8859-1 25000 avgt 10 11401.228 ? 563.124 ns/op ByteStreamDecoder.readStringReader UTF-8 256 avgt 10 1596.878 ? 43.824 ns/op ByteStreamDecoder.readStringReader UTF-8 4096 avgt 10 3349.961 ? 119.278 ns/op ByteStreamDecoder.readStringReader UTF-8 25000 avgt 10 13273.403 ? 591.600 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 256 avgt 10 1602.328 ? 44.092 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 4096 avgt 10 3403.312 ? 107.516 ns/op ByteStreamDecoder.readStringReader ISO-8859-6 25000 avgt 10 13163.468 ? 709.642 ns/op ByteStreamDecoder.readStringReader MS932 256 avgt 10 1602.837 ? 32.021 ns/op ByteStreamDecoder.readStringReader MS932 4096 avgt 10 3379.439 ? 87.716 ns/op ByteStreamDecoder.readStringReader MS932 25000 avgt 10 13376.980 ? 669.983 ns/op Performance degrades when you mix in non-ASCII characters, but so does the `new String(byte[], Charset)` baseline. While there might be algorithmic refinements possible to improve on some of the non-ASCII variants I'm happy to leave that to a follow-up and keep this RFE reasonably straightforward. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Mon Feb 15 14:55:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Feb 2021 14:55:46 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths Message-ID: This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. Testing: tier1-3 ------------- Commit messages: - Safer publication of JavaLangAccess - Logic error - Move creation of JavaLangAccess up before creating System.in/out - Fix typo (caught by Test4625418.java) - Merge branch 'master' into streamdecoder - Let decoders use String intrinsics to inflate ASCII-only bytes - Remove trailing spaces - Add microbenchmark - Simplify and improve StreamDecoder/-Encoder Changes: https://git.openjdk.java.net/jdk/pull/2574/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261744 Stats: 706 lines in 13 files changed: 300 ins; 107 del; 299 mod Patch: https://git.openjdk.java.net/jdk/pull/2574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574 PR: https://git.openjdk.java.net/jdk/pull/2574 From clanger at openjdk.java.net Mon Feb 15 15:07:55 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 15 Feb 2021 15:07:55 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 [v2] In-Reply-To: References: Message-ID: > After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. > > java.lang.Error: 11.2 != 11.2.1 > > This is a proposal to relax the test and throw a SkippedException in such cases. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Simplify the coding, use startsWith comparison ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2576/files - new: https://git.openjdk.java.net/jdk/pull/2576/files/6c52a6db..f06114c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2576/head:pull/2576 PR: https://git.openjdk.java.net/jdk/pull/2576 From rriggs at openjdk.java.net Mon Feb 15 15:10:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 15 Feb 2021 15:10:41 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 [v2] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 15:07:55 GMT, Christoph Langer wrote: >> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. >> >> java.lang.Error: 11.2 != 11.2.1 >> >> This is a proposal to relax the test and throw a SkippedException in such cases. > > Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: > > Simplify the coding, use startsWith comparison Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2576 From redestad at openjdk.java.net Mon Feb 15 15:19:01 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Feb 2021 15:19:01 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: > This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. > > - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. > - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting > - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert rem assertions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2574/files - new: https://git.openjdk.java.net/jdk/pull/2574/files/8da49e16..b0bf8cfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574 PR: https://git.openjdk.java.net/jdk/pull/2574 From burban at openjdk.java.net Mon Feb 15 16:24:48 2021 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 15 Feb 2021 16:24:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 12:22:09 GMT, Vladimir Kempik wrote: >> Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info. > > This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. > @lewurm could you comment here please Those values can be observed in the debugger, but aren't documented or defined in header files. This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:34:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:34:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v14] In-Reply-To: References: Message-ID: <6SmGFRbH6_SgIW-aRpEIrRnfsv-BI2nmDUffhObbyu8=.e4979c82-2bfb-4932-b980-d261d7a55f74@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - Fix inclusing of StubRoutines header - Redo buildsys fix - ... and 63 more: https://git.openjdk.java.net/jdk/compare/40ae9937...4094f351 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=13 Stats: 3066 lines in 84 files changed: 2954 ins; 47 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:45:07 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:45:07 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Pull/2200 (#5) * bsd_aarch64 cleanup * remove the actual attribute too * Refactor bailing out on nativeWrapper generation * rename c_call_conv_priv function - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos Additional work for JDK-8253817: Support macOS Aarch64 ABI in Interpreter - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945 - Update signal handler part for debugger - Cleanup SA changes - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - support macos_aarch64 in hsdis - Merge branch 'master' into jdk-macos - Update copyright year for BsdAARCH64ThreadContext.java - ... and 65 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...a9452a4c ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14 Stats: 3032 lines in 83 files changed: 2919 ins; 47 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 17:48:48 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 17:48:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15] In-Reply-To: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> References: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> Message-ID: On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote: >> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. > > Hello > Does this look like something in the right direction ? > > https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49 The latest merge with JDK-8261071 should resolve the issue. Please take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From dfuchs at openjdk.java.net Mon Feb 15 17:59:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 15 Feb 2021 17:59:38 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7] In-Reply-To: <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> Message-ID: On Fri, 12 Feb 2021 20:27:00 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? >> >> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8252399: Converted JavadocExamples to test These changes look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2544 From vkempik at openjdk.java.net Mon Feb 15 18:03:55 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 15 Feb 2021 18:03:55 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 1 Feb 2021 18:44:48 GMT, Andrew Haley wrote: >> Anton Kozlov 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 jdk-macos >> - Update copyright year for BsdAARCH64ThreadContext.java >> - Fix inclusing of StubRoutines header >> - Redo buildsys fix >> - Revert harfbuzz changes, disable warnings for it >> - Little adjustement of SlowSignatureHandler >> - Partially bring previous commit >> - Revert "Address feedback for signature generators" >> >> This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d. >> - Refactor CDS disabling >> - Redo builsys support for aarch64-darwin >> - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4 > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: > >> 837: // The code unable to handle this, bailout. >> 838: return -1; >> 839: #endif > > This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Mon Feb 15 18:03:51 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 15 Feb 2021 18:03:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:52:47 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: > >> 808: #ifdef __APPLE__ >> 809: // Less-than word types are stored one after another. >> 810: // The code unable to handle this, bailout. > > Perhaps: // The code is unable to handle this so bailout. Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 18:03:56 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:03:56 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote: > I'm going to do as much refactoring as needed before this patch under JDK-8261071 The recent merge resolves inconsitency between pass_byte/pass_short and other methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Mon Feb 15 18:10:09 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:10:09 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v16] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #6 from VladimirKempik/pull/2200 Fix typo in comments - Fix typo in comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/a9452a4c..419c2b1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From jboes at openjdk.java.net Mon Feb 15 18:18:39 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Feb 2021 18:18:39 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8] In-Reply-To: References: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com> <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com> Message-ID: On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java >> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java >> >> make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java" >> >> Building target 'test' in configuration 'windows-x86_64-server-release' >> Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run: >> * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> >> Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Passed: sun/security/tools/jarsigner/TimestampCheck.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java >> >> Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Passed: sun/security/tools/keytool/DefaultOptions.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java >> >> Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java >> Test results: passed: 1 >> Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html >> Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java' >> Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java >> 1 1 0 0 >> jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java >> 1 1 0 0 >> jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> Finished building target 'test' in configuration 'windows-x86_64-server-release' > > ## jdk/jshell/ToolBasicTest.java > > make test TEST="jtreg:jdk/jshell/ToolBasicTest.java" > > STDOUT: > [TestNG] Running: > jdk/jshell/ToolBasicTest.java > > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromList(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.elideStartUpFromSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.test8142447(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testAddExports(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testBadSourceJarClasspath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathDirectory(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathJar(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testClasspathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testConstrainedUpdates(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testCtrlD(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testEnvInStartUp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNegative(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackNormal(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testFeedbackSilent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testHistoryReference(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testIndent(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testInterrupt(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testLoadingFromArgs(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePath(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testModulePathUserHomeExpansion(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpen(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenFileOverHttp(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenLocalFileUrl(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testOpenResource(): failure > java.lang.AssertionError: user output: printf("%4.2f", Math.PI). > expected [3.14] but found [3,14] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:178) > at ReplToolTesting.assertOutput(ReplToolTesting.java:529) > at ReplToolTesting.assertCommand(ReplToolTesting.java:513) > at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559) > at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824) > at java.base/java.io.PrintStream.write(PrintStream.java:536) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294) > at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242) > at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321) > at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325) > at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159) > at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248) > at java.base/java.io.PrintWriter.flush(PrintWriter.java:396) > at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174) > at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626) > at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454) > at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testOpenResource(ToolBasicTest.java:555) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRedeclareVariableNoInit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRemoteExit(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerun(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testRerunIdRange(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testReset(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartRetain(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartSave(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStartupFileOption(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testStop(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testVarsWithNotActive(): success > config ReplToolTesting.setUp(): success > test ToolBasicTest.testWarningUnchecked(): success > > =============================================== > jdk/jshell/ToolBasicTest.java > Total tests run: 38, Failures: 1, Skips: 0 > =============================================== > > STDERR: > java.io.EOFException > at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398) > at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381) > at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277) > at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99) > at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160) > at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943) > at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139) > at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201) > at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991) > at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240) > at ReplToolTesting.testRawRun(ReplToolTesting.java:313) > at ReplToolTesting.testRaw(ReplToolTesting.java:296) > at ReplToolTesting.test(ReplToolTesting.java:249) > at ReplToolTesting.test(ReplToolTesting.java:233) > at ReplToolTesting.test(ReplToolTesting.java:229) > at ReplToolTesting.test(ReplToolTesting.java:225) > at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.Exception: failures: 1 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:831) > > JavaTest Message: Test threw exception: java.lang.Exception > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1 > > https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test. Hi @turbanoff, I ran tier 1-3 in our build and test system and can't reproduce the errors, they seem to be specific to the environment, as Alan hinted at. I also ran the jdk_jfr tests, which came back all clear. On another note, let's drop the change in sun.net.www.MimeLauncher, it's a jdk-internal class that is no longer used and can likely be removed. I opened a separate issue for that: https://bugs.openjdk.java.net/browse/JDK-8261750. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From akozlov at openjdk.java.net Mon Feb 15 18:24:08 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 15 Feb 2021 18:24:08 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v17] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - Removed unused variables ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/419c2b1a..90e244e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=15-16 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 18:33:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 18:33:00 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: References: Message-ID: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo revert changes from MimeLauncher ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6a8a3ae6..6614a10f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08-09 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From mcimadamore at openjdk.java.net Mon Feb 15 18:53:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 15 Feb 2021 18:53:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes from MimeLauncher The changes to sjavac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1853 From aph at openjdk.java.net Mon Feb 15 19:10:47 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 15 Feb 2021 19:10:47 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839: >> >>> 837: // The code unable to handle this, bailout. >>> 838: return -1; >>> 839: #endif >> >> This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention. > > Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. I don't understand why you think it's acceptable to bail in this case. Can you explain, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+7693005+jarviscraft at openjdk.java.net Mon Feb 15 19:22:41 2021 From: github.com+7693005+jarviscraft at openjdk.java.net (PROgrm_JARvis) Date: Mon, 15 Feb 2021 19:22:41 GMT Subject: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached In-Reply-To: References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com> <3-ZY2ZJ8vzS4N1TjawkxraNiIn1Xuf5eHTAqStPPtfs=.fae07aab-54ca-4a00-9d08-47905270c16e@github.com> <9D9f7yjySSwAQ6QE-zWc4WX-QJc9VnnvYx79x4NKWbA=.1fe2e647-d84e-4276-993a-304f39037dac@github.com> <24m8mszdoMDnQDl0v7b5TigYmUgbytkXignccj6E9pA=.a5a28bd0-3a59-47b6-acad-8bfc7199d7c0@github.com> <09_eDwenSVRPiK21p7X60n_F4oDd5Jg4xvQ WBYEmhAQ=.67915978-15ba-4406-9e8a-cb342cadeb42@github.com> Message-ID: <6Kww4QHiltSEaYOr-gkm0l9HIfIPfIwT7jEW50PxgsY=.5a2ee8ae-e2ab-4945-94b1-8b94ccad83bf@github.com> On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints) > >> >> >> @JarvisCraft This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! > @JarvisCraft Can you re-run your benchmarks in light of the changes that @cl4es pointed out in the previous comment? We think this PR can be closed. My apologies for the late reply, I'll try re-running these with the merged branch ASAP (the delay is due to me changing the workstation thus having some job to reconfigure the environment). ------------- PR: https://git.openjdk.java.net/jdk/pull/1821 From alanb at openjdk.java.net Mon Feb 15 19:25:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Feb 2021 19:25:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > revert changes from MimeLauncher src/java.management/share/classes/javax/management/loading/MLet.java line 1149: > 1147: file.deleteOnExit(); > 1148: Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING); > 1149: if (file.exists()) { You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 19:47:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 19:47:01 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10] In-Reply-To: References: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com> Message-ID: <7bSIORe_urCOaP-rcSwcaRkhFU0rymCRLOk5s3t3PF4=.c340769a-e407-44c1-8704-fc7ea5eb7411@github.com> On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> revert changes from MimeLauncher > > src/java.management/share/classes/javax/management/loading/MLet.java line 1149: > >> 1147: file.deleteOnExit(); >> 1148: Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING); >> 1149: if (file.exists()) { > > You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds. You are right. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Mon Feb 15 19:47:00 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Feb 2021 19:47:00 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo remove unnecessary file.exists() check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6614a10f..6e71e961 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+471021+marschall at openjdk.java.net Mon Feb 15 19:59:43 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 15 Feb 2021 19:59:43 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: References: Message-ID: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad wrote: >> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. >> >> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. >> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting >> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. >> >> Testing: tier1-3 > > On the best-case microbenchmark (the byte stream is all ASCII), speed-ups are quite telling: > > Before: > Benchmark (charsetName) (length) Mode Cnt Score Error Units > ByteStreamDecoder.readStringReader US-ASCII 256 avgt 10 2085.399 ? 66.522 ns/op > ByteStreamDecoder.readStringReader US-ASCII 4096 avgt 10 12466.702 ? 747.116 ns/op > ByteStreamDecoder.readStringReader US-ASCII 25000 avgt 10 123508.987 ? 3583.345 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 256 avgt 10 1894.185 ? 51.772 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 4096 avgt 10 8117.404 ? 594.708 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 25000 avgt 10 99409.792 ? 28308.936 ns/op > ByteStreamDecoder.readStringReader UTF-8 256 avgt 10 2090.337 ? 56.500 ns/op > ByteStreamDecoder.readStringReader UTF-8 4096 avgt 10 11698.221 ? 898.910 ns/op > ByteStreamDecoder.readStringReader UTF-8 25000 avgt 10 66568.987 ? 4204.361 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 256 avgt 10 3061.130 ? 120.132 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 4096 avgt 10 24623.494 ? 1916.362 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 25000 avgt 10 139138.140 ? 7109.636 ns/op > ByteStreamDecoder.readStringReader MS932 256 avgt 10 2612.535 ? 98.638 ns/op > ByteStreamDecoder.readStringReader MS932 4096 avgt 10 18843.438 ? 1767.822 ns/op > ByteStreamDecoder.readStringReader MS932 25000 avgt 10 119923.997 ? 18560.065 ns/op > > After: > Benchmark (charsetName) (length) Mode Cnt Score Error Units > ByteStreamDecoder.readStringReader US-ASCII 256 avgt 10 1556.588 ? 37.083 ns/op > ByteStreamDecoder.readStringReader US-ASCII 4096 avgt 10 3290.627 ? 125.327 ns/op > ByteStreamDecoder.readStringReader US-ASCII 25000 avgt 10 13118.794 ? 597.086 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 256 avgt 10 1525.460 ? 36.510 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 4096 avgt 10 3051.887 ? 113.036 ns/op > ByteStreamDecoder.readStringReader ISO-8859-1 25000 avgt 10 11401.228 ? 563.124 ns/op > ByteStreamDecoder.readStringReader UTF-8 256 avgt 10 1596.878 ? 43.824 ns/op > ByteStreamDecoder.readStringReader UTF-8 4096 avgt 10 3349.961 ? 119.278 ns/op > ByteStreamDecoder.readStringReader UTF-8 25000 avgt 10 13273.403 ? 591.600 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 256 avgt 10 1602.328 ? 44.092 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 4096 avgt 10 3403.312 ? 107.516 ns/op > ByteStreamDecoder.readStringReader ISO-8859-6 25000 avgt 10 13163.468 ? 709.642 ns/op > ByteStreamDecoder.readStringReader MS932 256 avgt 10 1602.837 ? 32.021 ns/op > ByteStreamDecoder.readStringReader MS932 4096 avgt 10 3379.439 ? 87.716 ns/op > ByteStreamDecoder.readStringReader MS932 25000 avgt 10 13376.980 ? 669.983 ns/op > > Performance degrades when you mix in non-ASCII characters, but so does the `new String(byte[], Charset)` baseline. While there might be algorithmic refinements possible to improve on some of the non-ASCII variants I'm happy to leave that to a follow-up and keep this RFE reasonably straightforward. Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Mon Feb 15 20:37:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 15 Feb 2021 20:37:39 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> References: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> Message-ID: On Mon, 15 Feb 2021 19:56:32 GMT, Philippe Marschall wrote: > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From vkempik at openjdk.java.net Tue Feb 16 06:26:46 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 16 Feb 2021 06:26:46 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley wrote: >> Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered > > This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. > I don't understand why you think it's acceptable to bail in this case. Can you explain, please? it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)). currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented. So when a method has more argument than can be placed in registers, we may have issues. So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack. There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Tue Feb 16 07:42:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Feb 2021 07:42:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > remove unnecessary file.exists() check Thanks for perceiving with this one. I think you've addressed all issues in the latest revision. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1853 From mbaesken at openjdk.java.net Tue Feb 16 08:47:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 16 Feb 2021 08:47:39 GMT Subject: Integrated: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote: > JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage This pull request has now been integrated. Changeset: 219b115e Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/219b115e Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage Reviewed-by: clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From alanb at openjdk.java.net Tue Feb 16 08:53:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Feb 2021 08:53:41 GMT Subject: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage In-Reply-To: <51otobW2pPoE0hrya652T-QHv7O9L5KwlwsP6uLjN5M=.60533500-483b-44ba-84b8-590a752c1da4@github.com> References: <51otobW2pPoE0hrya652T-QHv7O9L5KwlwsP6uLjN5M=.60533500-483b-44ba-84b8-590a752c1da4@github.com> Message-ID: On Fri, 12 Feb 2021 11:02:36 GMT, Christoph Langer wrote: >> JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage > > As we're potentially formatting any "Number" type here, theoretically floats could be passed which would result in an Exception. In fact, only decimal types are passed by the callers so this should not happen. Unfortunately there's no super type specifying decimal numbers. > > And as we're not doing some fancy formatting but just %d, I think replacing this with %s should be ok. I see this change been integrated but there is further work required on the test coverage. Are you planing to do code coverage and create a follow-on issue to add more tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/2483 From ewhelan at openjdk.java.net Tue Feb 16 11:37:10 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 11:37:10 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: <8YnjBOfsUbDfDcGrQiNgpkBr_z1w3DikTTHXnyiX_mw=.728db53e-e44d-45e1-a6f6-d0fe1a2ab18f@github.com> On Mon, 15 Feb 2021 12:55:46 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching > > src/java.logging/share/classes/java/util/logging/FileHandler.java line 39: > >> 37: import java.nio.channels.FileChannel; >> 38: import java.nio.channels.OverlappingFileLockException; >> 39: import java.nio.file.*; > > We avoid using the wildcard with imports in the JDK sources. Could you revert that change? Yes, reverted thanks > src/java.logging/share/classes/java/util/logging/FileHandler.java line 512: > >> 510: // Try again. If it doesn't work, then this will >> 511: // eventually ensure that we increment "unique" and >> 512: // use another file name. > > I believe this would be more clear if the comment was put inside the if statement, just before continue. > It might be good to add some words about what might be causing the AccessDeniedException as well... > Maybe something like: > > } catch (AccessDeniedException ade) { > // This can be either a temporary, or a more permanent issue. > // The lock file might be still pending deletion from a previous run > // (temporary), or the parent directory might not be accessible, etc... > // If we can write to the current directory, and this is a regular file, > // let's try again. > if (Files.isRegularFile(lockFilePath, LinkOption.NOFOLLOW_LINKS) > && isParentWritable(lockFilePath)) { > // Try again. If it doesn't work, then this will > // eventually ensure that we increment "unique" and > // use another file name. > continue; > } else { > throw ade; // no need to retry > } ... I agree. I've updated the comments > test/jdk/java/util/logging/FileHandlerAccessTest.java line 47: > >> 45: if (!(args.length == 2 || args.length == 1)) { >> 46: System.out.println("Usage error: expects java FileHandlerAccessTest [process/thread] "); >> 47: System.exit(1); > > We usually avoid `System.exit()` in tests. `return` should be enough. Changed to `return` > test/jdk/java/util/logging/FileHandlerAccessTest.java line 75: > >> 73: } >> 74: catch(Exception e) { >> 75: e.printStackTrace(); > > If you only print exceptions, when does the test fail? Thanks for catching this. I've updated the test to throw the exceptions rather than printing stack trace. This was a modified version of the test for debugging purposes. It's worth noting that it's not possible to write a test which can deterministically prove/ verify the behaviour (and related fix) of the parent bug as this involves the situation where multiple threads conflict on a Windows machine. The test attached is a best-effort and was tried around 40 times. > test/jdk/java/util/logging/FileHandlerAccessTest.java line 98: > >> 96: childProcess.waitFor(); >> 97: } >> 98: catch(Exception e) { > > space missing after `catch` Fixed > test/jdk/java/util/logging/FileHandlerAccessTest.java line 99: > >> 97: } >> 98: catch(Exception e) { >> 99: e.printStackTrace(); > > Same remark here: should this make the test fail? Thanks Daniel, please see my above reply > test/jdk/java/util/logging/FileHandlerAccessTest.java line 101: > >> 99: e.printStackTrace(); >> 100: } >> 101: finally { > > I would prefer if `catch` and `finally` where on the same line than the preceding closing brace: > > try { > ... > } catch (...) { > ... > } finally { > ... > } Fixed > test/jdk/java/util/logging/FileHandlerAccessTest.java line 106: > >> 104: } >> 105: if (bufferedReader != null){ >> 106: try{ > > space missing after `try` Fixed > test/jdk/java/util/logging/FileHandlerAccessTest.java line 109: > >> 107: bufferedReader.close(); >> 108: } >> 109: catch(Exception ignored){} > > space missing after `catch` Fixed > test/jdk/java/util/logging/FileHandlerAccessTest.java line 113: > >> 111: } >> 112: } >> 113: } > > Please add a newline at the end of the file. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Tue Feb 16 11:37:05 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 11:37:05 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/045d725f..e755d323 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=00-01 Stats: 36 lines in 2 files changed: 13 ins; 5 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Tue Feb 16 11:37:06 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 11:37:06 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 11:33:08 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching Daniel's suggestions have been integrated to the patch ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Tue Feb 16 11:51:47 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 16 Feb 2021 11:51:47 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 11:37:05 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching Thanks for taking on the changes. Still some comments... test/jdk/java/util/logging/FileHandlerAccessTest.java line 75: > 73: handler.close(); > 74: } catch (Exception e) { > 75: throw new RuntimeException(e); Will throwing an exception in a thread (if happening in the Thread created at line 60) cause jtreg to fail? Or will the exception simply be discarded? test/jdk/java/util/logging/FileHandlerAccessTest.java line 98: > 96: childProcess.waitFor(); > 97: } catch (Exception e) { > 98: throw new RuntimeException(e); Same holds there as well. Maybe you could make an experiment with a dummy test to see whether the exception will make the test fail. test/jdk/java/util/logging/FileHandlerAccessTest.java line 96: > 94: System.out.println(name + "\t|" + line); > 95: } > 96: childProcess.waitFor(); Should you be checking the status returned by `waitFor` and fail the test if it's not `0`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From jdk at fiolino.de Tue Feb 16 12:34:30 2021 From: jdk at fiolino.de (Michael Kuhlmann) Date: Tue, 16 Feb 2021 13:34:30 +0100 Subject: System.getEnv(String name, String def) In-Reply-To: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> References: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> Message-ID: <1b208826-6371-e623-5321-f7586b9358cd@fiolino.de> Hi R?mi, I don't want to be pedantic, but I see this as an anti-pattern. You would create an Optional just to immediately call orElse() on it. That's not how Optional should be used. (But you know that.) It's described in Recipe 12 of this Java Magazine article, for instance: https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used Best, Michael On 2/15/21 3:09 PM, Remi Forax wrote: > Hi Loic, > You can use Optional.OfNullable() which is a kind of the general bridge between the nullable world and the non-nullable one. > > var fooOptional = Optional.ofNullable(System.getenv("FOO")); > var fooValue = fooOptional.orElse(defaultValue); > > regards, > R?mi Forax > > ----- Mail original ----- >> De: "Lo?c MATHIEU" >> ?: "core-libs-dev" >> Envoy?: Lundi 15 F?vrier 2021 14:59:42 >> Objet: System.getEnv(String name, String def) > >> Hello, >> >> I wonder if there has already been some discussion to provide >> a System.getEnv(String name, String def) method that allows to return a >> default value in case the env variable didn't exist. >> >> When using system properties instead of env variable, we do have a >> System.getProperty(String key, String def) variant. >> >> Stating the JavaDoc of System.getEnv(): >> *System properties and environment variables are both conceptually mappings >> between names and values* >> >> So if system properties and environment variables are similar concepts, >> they should provide the same functionalities right ? >> >> This would be very convenient as more and more people rely on >> environment variables these days to configure their applications. >> >> Regards, >> >> Lo?c From clanger at openjdk.java.net Tue Feb 16 13:02:54 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 16 Feb 2021 13:02:54 GMT Subject: RFR: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 [v3] In-Reply-To: References: Message-ID: > After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. > > java.lang.Error: 11.2 != 11.2.1 > > This is a proposal to relax the test and throw a SkippedException in such cases. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2576/files - new: https://git.openjdk.java.net/jdk/pull/2576/files/f06114c9..9fe46d7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2576&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2576/head:pull/2576 PR: https://git.openjdk.java.net/jdk/pull/2576 From clanger at openjdk.java.net Tue Feb 16 13:02:55 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 16 Feb 2021 13:02:55 GMT Subject: Integrated: 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 13:27:36 GMT, Christoph Langer wrote: > After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java still fails on BigSur versions that have a patch version (> 1), e.g. on macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12. > > java.lang.Error: 11.2 != 11.2.1 > > This is a proposal to relax the test and throw a SkippedException in such cases. This pull request has now been integrated. Changeset: 8ba390d1 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/8ba390d1 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod 8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702 Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/2576 From redestad at openjdk.java.net Tue Feb 16 13:48:43 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 13:48:43 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: References: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> Message-ID: On Mon, 15 Feb 2021 20:34:53 GMT, Claes Redestad wrote: > > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? > > Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617 It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From jlaskey at openjdk.java.net Tue Feb 16 14:06:56 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 16 Feb 2021 14:06:56 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 15:03:53 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added table of available algorithms. > > src/java.base/share/classes/java/util/Random.java line 29: > >> 27: >> 28: import java.io.*; >> 29: import java.math.BigInteger; > > This import is not actually used good > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 115: > >> 113: static final String BAD_BOUND = "bound must be positive"; >> 114: static final String BAD_FLOATING_BOUND = "bound must be finite and positive"; >> 115: static final String BAD_RANGE = "bound must be greater than origin"; > > Unused fields in Random class now can be cleaned up: `java.util.Random#BadRange`, `java.util.Random#BadSize` Good > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 149: > >> 147: */ >> 148: public static void checkJumpDistance(double distance) { >> 149: if (!(distance > 0.0 && distance < Float.POSITIVE_INFINITY > > I wounder if this usage of `Float.POSITIVE_INFINITY` intentional here? Looks a bit suspicious for comparison with `double` argument Turns out the method is no longer used. > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: > >> 1546: * @return a stream of (pseudo)randomly chosen {@code int} values >> 1547: */ >> 1548: > > Is `@Override` intentionally omitted? The interface method is a default method, so not technically an override. > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1943: > >> 1941: >> 1942: // IllegalArgumentException messages >> 1943: static final String BadLogDistance = "logDistance must be non-negative"; > > seems unused Good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From vkempik at openjdk.java.net Tue Feb 16 14:09:54 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 16 Feb 2021 14:09:54 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10] In-Reply-To: References: Message-ID: <44L8Jccum5-J3RntkBsRZJ5daAJ-X1tYt_4xspIbP6U=.4dd53895-2fb7-4396-82e1-8387828bcdbf@github.com> On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >> + minor change of placements >> - Use macro conditionals instead of empty functions >> - Add W^X to tests >> - Do not require known W^X state >> - Revert w^x in gtests > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297: > >> 295: stub = SharedRuntime::handle_unsafe_access(thread, next_pc); >> 296: } >> 297: } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { > > Can we add a comment here describing what this case means? This was added as part of this commit ( to linux_aarch64) - https://github.com/openjdk/jdk/commit/339d52600b285eb3bc57d9ff107567d4424efeb1 @gerard-ziemski do we really want to add anything new here ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From alanb at openjdk.java.net Tue Feb 16 15:08:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Feb 2021 15:08:38 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: References: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> Message-ID: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com> On Tue, 16 Feb 2021 13:45:41 GMT, Claes Redestad wrote: >>> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? >> >> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. > >> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? >> >> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. > > Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617 > > It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication. This looks a really good change and it's great can these decoders get the benefit of the instrinics work. ISO_8869_1.decodeArrayLoop using JLA.inflate looks a bit strange and maybe we can rename the method in the shared secret to inflatedCopy or just copy. or just add a comment. The reason is that code outside of java.lang shouldn't know anything about String's internals and inflation. The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file. I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here). I expect Naoto will want to review this PR too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Tue Feb 16 15:16:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 15:16:38 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com> References: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com> Message-ID: On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman wrote: >>> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? >>> >>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. >> >> Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617 >> >> It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication. > > This looks a really good change and it's great can these decoders get the benefit of the instrinics work. > > ISO_8869_1.decodeArrayLoop using JLA.inflate looks a bit strange and maybe we can rename the method in the shared secret to inflatedCopy or just copy. or just add a comment. The reason is that code outside of java.lang shouldn't know anything about String's internals and inflation. > > The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file. > > I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here). > > I expect Naoto will want to review this PR too. I added the `Inflated copy from byte[] to char[], as defined by StringLatin1` comment to the `inflate` method in `JavaLangAccess`, but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Tue Feb 16 15:53:38 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 15:53:38 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com> References: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com> <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com> Message-ID: On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman wrote: > The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file. > Apart from a few things being made final that weren't, and a flattening of a back-to-back Charset lookup in one of the constructors its mostly formatting cleanups. > I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here). Right, I'm not exactly sure why the more limited changes I attempted in 5f4e87f failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From github.com+828220+forax at openjdk.java.net Tue Feb 16 15:56:48 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 16 Feb 2021 15:56:48 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 14:03:56 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1548: >> >>> 1546: * @return a stream of (pseudo)randomly chosen {@code int} values >>> 1547: */ >>> 1548: >> >> Is `@Override` intentionally omitted? > > The interface method is a default method, so not technically an override. It's not an override but @Override has a broader semantics than just overriding an existing method. Given that it helps to understand that this method is part of a larger algorithm, i think this method should be tagged with @Override ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Tue Feb 16 16:21:43 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 16 Feb 2021 16:21:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 15:54:08 GMT, R?mi Forax wrote: >> The interface method is a default method, so not technically an override. > > It's not an override but @Override has a broader semantics than just overriding an existing method. > Given that it helps to understand that this method is part of a larger algorithm, i think this method should be tagged with @Override Okay ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From rriggs at openjdk.java.net Tue Feb 16 16:32:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 16 Feb 2021 16:32:44 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 22:52:06 GMT, Joe Darcy wrote: >> A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. >> >> Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From ewhelan at openjdk.java.net Tue Feb 16 16:46:42 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 16:46:42 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 11:33:08 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching > > test/jdk/java/util/logging/FileHandlerAccessTest.java line 75: > >> 73: handler.close(); >> 74: } catch (Exception e) { >> 75: throw new RuntimeException(e); > > Will throwing an exception in a thread (if happening in the Thread created at line 60) cause jtreg to fail? Or will the exception simply be discarded? The exception will in fact make the jtreg test fail. I verified this by creating a dummy test case and throwing an exception within a thread as you suggested. > test/jdk/java/util/logging/FileHandlerAccessTest.java line 98: > >> 96: childProcess.waitFor(); >> 97: } catch (Exception e) { >> 98: throw new RuntimeException(e); > > Same holds there as well. Maybe you could make an experiment with a dummy test to see whether the exception will make the test fail. Please see above comment. Verified that an exception thrown within a thread causes test to fail ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Tue Feb 16 16:49:44 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 16:49:44 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 11:48:05 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Doc cleanup, code formatting and throwing exceptions instead of catching > > test/jdk/java/util/logging/FileHandlerAccessTest.java line 96: > >> 94: System.out.println(name + "\t|" + line); >> 95: } >> 96: childProcess.waitFor(); > > Should you be checking the status returned by `waitFor` and fail the test if it's not `0`? I'll modify the code to add this behaviour. Thanks for the suggestion :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From jboes at openjdk.java.net Tue Feb 16 17:23:42 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 16 Feb 2021 17:23:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: Message-ID: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From joehw at openjdk.java.net Tue Feb 16 17:26:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 16 Feb 2021 17:26:39 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: On Sun, 14 Feb 2021 21:27:49 GMT, Naoto Sato wrote: >> Adds a property similar to 'isStandalone' in JDK-8249867. >> >> Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. > > test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 107: > >> 105: + "\n" >> 106: + ""; >> 107: > > Could be better to use text blocks? In general, we're keeping it at source level 8 to facilitate backports. As a result, only a few projects so far have been done using more advanced features. ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From naoto at openjdk.java.net Tue Feb 16 17:47:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 16 Feb 2021 17:47:38 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 00:16:50 GMT, Joe Wang wrote: > Adds a property similar to 'isStandalone' in JDK-8249867. > > Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From naoto at openjdk.java.net Tue Feb 16 17:47:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 16 Feb 2021 17:47:40 GMT Subject: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: <64BcXIpDPqwuTjZ1DKlcKprsCCr6ORbKF32AaHhoV0I=.41a0e0cc-df56-4149-a2b4-dd54a91841c8@github.com> On Tue, 16 Feb 2021 17:23:35 GMT, Joe Wang wrote: >> test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 107: >> >>> 105: + "\n" >>> 106: + ""; >>> 107: >> >> Could be better to use text blocks? > > In general, we're keeping it at source level 8 to facilitate backports. As a result, only a few projects so far have been done using more advanced features. Makes sense. Thanks for the explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From naoto at openjdk.java.net Tue Feb 16 17:59:51 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 16 Feb 2021 17:59:51 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v3] In-Reply-To: References: Message-ID: > Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Removed empty

      tag - 8261621: Delegate Unicode history from JLS to j.l.Character ------------- Changes: https://git.openjdk.java.net/jdk/pull/2538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=02 Stats: 36 lines in 1 file changed: 34 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538 PR: https://git.openjdk.java.net/jdk/pull/2538 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:44:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:44:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: References: Message-ID: <04LMLK3YO1cEPtchQl39EhAgeSN2mvEdQONQg_UzLKc=.7d1ce34f-04b6-4248-ba32-efec0c24b915@github.com> On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> fix review comments > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230: > >> 228: // Copy the entire input stream into an InputStream that does >> 229: // support mark >> 230: is = new ByteArrayInputStream(is.readAllBytes()); > > I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do: > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); Good idea. Will improve. By the way, code in `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` looks suspicious: it reads only `InputStream.available()` bytes, which doesn't make much sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:47:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:47:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v9] In-Reply-To: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> References: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com> Message-ID: On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> fix review comments > > src/java.base/share/classes/java/util/jar/JarInputStream.java line 93: > >> 91: if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) { >> 92: man = new Manifest(); >> 93: byte[] bytes = new BufferedInputStream(this).readAllBytes(); > > I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7. > > In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly. Usage of `BufferedInputStream` removed ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From github.com+741251+turbanoff at openjdk.java.net Tue Feb 16 18:58:57 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Feb 2021 18:58:57 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v12] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/6e71e961..1b30471d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10-11 Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From naoto at openjdk.java.net Tue Feb 16 19:53:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 16 Feb 2021 19:53:41 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 15:19:01 GMT, Claes Redestad wrote: >> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. >> >> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. >> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting >> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert rem assertions Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned. src/java.base/share/classes/java/lang/String.java line 1017: > 1015: * @return the number of bytes successfully decoded, at most len > 1016: */ > 1017: /* package-private */ Some more explanation would be helpful here, as it is accessed from System for shared secrets. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 48: > 46: import jdk.internal.module.ServicesCatalog; > 47: import jdk.internal.reflect.ConstantPool; > 48: import jdk.internal.vm.annotation.IntrinsicCandidate; Not needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Tue Feb 16 20:22:20 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 20:22:20 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v3] In-Reply-To: References: Message-ID: > This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. > > - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. > - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting > - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Copyrights - Review fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2574/files - new: https://git.openjdk.java.net/jdk/pull/2574/files/b0bf8cfb..367be2a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=01-02 Stats: 15 lines in 10 files changed: 1 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574 PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Tue Feb 16 20:22:25 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 20:22:25 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 19:48:09 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert rem assertions > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 48: > >> 46: import jdk.internal.module.ServicesCatalog; >> 47: import jdk.internal.reflect.ConstantPool; >> 48: import jdk.internal.vm.annotation.IntrinsicCandidate; > > Not needed. Fixed > src/java.base/share/classes/java/lang/String.java line 1017: > >> 1015: * @return the number of bytes successfully decoded, at most len >> 1016: */ >> 1017: /* package-private */ > > Some more explanation would be helpful here, as it is accessed from System for shared secrets. Ok, added a short comment ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From forax at univ-mlv.fr Tue Feb 16 20:59:13 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Feb 2021 21:59:13 +0100 (CET) Subject: System.getEnv(String name, String def) In-Reply-To: <1b208826-6371-e623-5321-f7586b9358cd@fiolino.de> References: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> <1b208826-6371-e623-5321-f7586b9358cd@fiolino.de> Message-ID: <694130485.1268749.1613509153830.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Michael Kuhlmann" > ?: "core-libs-dev" > Envoy?: Mardi 16 F?vrier 2021 13:34:30 > Objet: Re: System.getEnv(String name, String def) > Hi R?mi, > > I don't want to be pedantic, but I see this as an anti-pattern. You > would create an Optional just to immediately call orElse() on it. That's > not how Optional should be used. (But you know that.) > > It's described in Recipe 12 of this Java Magazine article, for instance: > https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used yep, you are right. Optional.ofNullable(...).orElse(...) is not the best pattern in term of readability. > > Best, > Michael regards, R?mi > > On 2/15/21 3:09 PM, Remi Forax wrote: >> Hi Loic, >> You can use Optional.OfNullable() which is a kind of the general bridge between >> the nullable world and the non-nullable one. >> >> var fooOptional = Optional.ofNullable(System.getenv("FOO")); >> var fooValue = fooOptional.orElse(defaultValue); >> >> regards, >> R?mi Forax >> >> ----- Mail original ----- >>> De: "Lo?c MATHIEU" >>> ?: "core-libs-dev" >>> Envoy?: Lundi 15 F?vrier 2021 14:59:42 >>> Objet: System.getEnv(String name, String def) >> >>> Hello, >>> >>> I wonder if there has already been some discussion to provide >>> a System.getEnv(String name, String def) method that allows to return a >>> default value in case the env variable didn't exist. >>> >>> When using system properties instead of env variable, we do have a >>> System.getProperty(String key, String def) variant. >>> >>> Stating the JavaDoc of System.getEnv(): >>> *System properties and environment variables are both conceptually mappings >>> between names and values* >>> >>> So if system properties and environment variables are similar concepts, >>> they should provide the same functionalities right ? >>> >>> This would be very convenient as more and more people rely on >>> environment variables these days to configure their applications. >>> >>> Regards, >>> > >> Lo?c From ewhelan at openjdk.java.net Tue Feb 16 21:15:58 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 16 Feb 2021 21:15:58 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v3] In-Reply-To: References: Message-ID: <6yFge-pMXKus66tDpDNzp6QdBB_ZtLSYgDbQfM-Cm0Q=.4e9cacd4-8416-4468-8ef5-68da3f106ed8@github.com> > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8252883: Throw exception if exit code of child process is non-zero ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/e755d323..9472f73c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=01-02 Stats: 9 lines in 1 file changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From igraves at openjdk.java.net Tue Feb 16 22:03:03 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 16 Feb 2021 22:03:03 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* Message-ID: Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. ------------- Commit messages: - Changing Collections.unmodifiable* to idempotent behavior. Changes: https://git.openjdk.java.net/jdk/pull/2596/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6323374 Stats: 281 lines in 2 files changed: 281 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596 From rriggs at openjdk.java.net Tue Feb 16 22:20:51 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 16 Feb 2021 22:20:51 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v3] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 17:59:51 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. > > Naoto Sato 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: > > - Removed empty

      tag > - 8261621: Delegate Unicode history from JLS to j.l.Character Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From rriggs at openjdk.java.net Tue Feb 16 22:22:38 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 16 Feb 2021 22:22:38 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves wrote: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Please add a space after `if` -> `if `. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From mchung at openjdk.java.net Tue Feb 16 22:32:07 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 16 Feb 2021 22:32:07 GMT Subject: RFR: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library Message-ID: Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java to use ForceGC from test library which has additional instrumentation to diagnose problem. In addition, this will get the fix for JDK-8258007. ------------- Commit messages: - fix copyright header update - update copyright header - 8261851: update test to use ForceGC from test library Changes: https://git.openjdk.java.net/jdk/pull/2597/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2597&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261851 Stats: 39 lines in 1 file changed: 1 ins; 37 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2597.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2597/head:pull/2597 PR: https://git.openjdk.java.net/jdk/pull/2597 From redestad at openjdk.java.net Tue Feb 16 23:23:47 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 16 Feb 2021 23:23:47 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves wrote: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Changes requested by redestad (Reviewer). src/java.base/share/classes/java/util/Collections.java line 1130: > 1128: public static Set unmodifiableSet(Set s) { > 1129: if(s.getClass() == UnmodifiableSet.class || > 1130: s.getClass() == ImmutableCollections.Set12.class || These might be problematic: `ImmutableCollections.Set*` differs in behavior subtly from `UnmodifiableSet`, e.g., `set.contains(null)` will throw an NPE. I'd limit the check and optimization to `UnmodifiableSet` here src/java.base/share/classes/java/util/Collections.java line 1315: > 1313: public static List unmodifiableList(List list) { > 1314: if (list.getClass() == UnmodifiableList.class || list.getClass() == UnmodifiableRandomAccessList.class || > 1315: list.getClass() == ImmutableCollections.List12.class || Similar issue here src/java.base/share/classes/java/util/Collections.java line 1473: > 1471: public static Map unmodifiableMap(Map m) { > 1472: if(m.getClass() == UnmodifiableMap.class || > 1473: m.getClass() == ImmutableCollections.Map1.class || And here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From bpb at openjdk.java.net Tue Feb 16 23:54:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Feb 2021 23:54:41 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) In-Reply-To: References: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com> Message-ID: On Tue, 5 Jan 2021 00:48:54 GMT, Brian Burkhalter wrote: >> A couple of implementation notes: >> >> Reader#read(CharBuffer) >> >> on-heap case >> >> I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1. >> >> I am using a c-style array declaration because the rest of the class uses it. >> >> off-heap case >> >> I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations. >> >> A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. >> >> The implementation took inspiration from java.io.InputStream#readNBytes(int). >> >> InputStreamReader#read(CharBuffer) >> >> Since StreamDecoder is a Reader as well we can simply delegate. >> >> StreamDecoder#read(CharBuffer) >> >> Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers. >> >> on-heap case >> >> We see a performance improvement and the elimination of all intermediate allocation. >> >> StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer. >> >> off-heap case >> >> We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput. >> >> I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there: >> >> https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks >> >> An Excel with charts can be found here: >> >> https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx >> >> I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime. >> >> There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed. > > I changed the JBS issue summary to match the title of this PR so that integration blocker is removed. > > How does the off-heap performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied? > > Some kind of specific test should likely be included. > > Note that the more recent copyright year is now 2021. I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From bpb at openjdk.java.net Tue Feb 16 23:54:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Feb 2021 23:54:43 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 09:18:10 GMT, Philippe Marschall wrote: >> Implement three optimiztations for Reader.read(CharBuffer) >> >> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. >> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. >> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. >> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. > > Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: > > - Replace c-style array declarations > - Share work buffer between #skip and #read test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 34: > 32: import org.testng.annotations.Test; > 33: > 34: import java.io.*; It's generally better not to use a wild card. test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 73: > 71: } > 72: > 73: buffer.clear(); I think `buffer.rewind()` would be more in keeping with the specification verbiage although there will be no practical effect here. Same comment applies below and in the other test `ReadCharBuffer`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From darcy at openjdk.java.net Tue Feb 16 23:57:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 16 Feb 2021 23:57:11 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v7] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: <2Cq1crdcnToAfNJscmFgGXezSMVdD71GxgyIERtLW2U=.b0596963-959c-47f8-8cca-7f9b60779c4f@github.com> > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo in link. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/03f01e65..e27b6772 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Wed Feb 17 00:02:49 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 17 Feb 2021 00:02:49 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v6] In-Reply-To: References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: On Fri, 12 Feb 2021 23:31:04 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo. > > src/java.base/share/classes/java/math/BigDecimal.java line 99: > >> 97: * hold. The results of methods like {@link scale} and {@link >> 98: * unscaledValue} will differ for numerically equal values with >> 99: * different representations. > > While this text is correct and reasonable, it doesn't really explain _why_ equals() considers the representation. One might assume incorrectly that the representation is internal only and doesn't affect computations. Of course it does affect computations, which is why I suggested the example. Maybe the example doesn't belong right here, in which case it's reasonable for this change to proceed. I think it would be good to put an example _somewhere_ of non-substitutability of numerical values with different representations. Maybe we could handle that separately. I've filed DK-8261862: "Expand discussion of rationale for BigDecimal equals/compareTo semantics" as a follow-up bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Wed Feb 17 01:03:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 17 Feb 2021 01:03:14 GMT Subject: RFR: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods [v8] In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Reflow paragraphs. - Update copyright year. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2471/files - new: https://git.openjdk.java.net/jdk/pull/2471/files/e27b6772..51575059 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2471&range=06-07 Stats: 92 lines in 4 files changed: 8 ins; 2 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/2471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2471/head:pull/2471 PR: https://git.openjdk.java.net/jdk/pull/2471 From darcy at openjdk.java.net Wed Feb 17 01:11:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 17 Feb 2021 01:11:50 GMT Subject: Integrated: 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods In-Reply-To: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> References: <50YQYlLMlnxRXYCSewlF48SwG-S6rQJ7S_-BEOP0lgs=.9cdecfe9-8532-4201-8da0-50aac5a395da@github.com> Message-ID: <6E29f9R8DCitYAHOtmPl5_2LfsI7l_LI_CXmd5Q8vEI=.6f4f769d-fe8f-4ce9-8ac3-155c66c57187@github.com> On Tue, 9 Feb 2021 06:42:26 GMT, Joe Darcy wrote: > A follow-up of sorts to JDK-8257086, this change aims to improve the discussion of the relationship between Object.equals and compareTo and compare methods. The not-consistent-with-equals natural ordering of BigDecimal get more explication too. While updating Object, I added some uses of apiNote and implSpec, as appropriate. While a signum method did not exist when Comparable was added, it has existed for many years so I removed obsolete text that defined a "sgn" function to compute signum. > > Once the changes are agreed to, I'll reflow paragraphs and update the copyright years. This pull request has now been integrated. Changeset: d547e1a8 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d547e1a8 Stats: 151 lines in 4 files changed: 52 ins; 16 del; 83 mod 8261123: Augment discussion of equivalence classes in Object.equals and comparison methods Reviewed-by: bpb, smarks, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/2471 From github.com+297150+michaelhixson at openjdk.java.net Wed Feb 17 01:11:53 2021 From: github.com+297150+michaelhixson at openjdk.java.net (Michael Hixson) Date: Wed, 17 Feb 2021 01:11:53 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves wrote: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. src/java.base/share/classes/java/util/Collections.java line 1473: > 1471: public static Map unmodifiableMap(Map m) { > 1472: if(m.getClass() == UnmodifiableMap.class || > 1473: m.getClass() == ImmutableCollections.Map1.class || (I'm not a reviewer.) I think this causes a change in behavior to this silly program. var map1 = Map.of(1, 2); var map2 = Collections.unmodifiableMap(map1); try { System.out.println("map1 returned " + map1.entrySet().contains(null)); } catch (NullPointerException e) { System.out.println("map1 threw"); } try { System.out.println("map2 returned " + map2.entrySet().contains(null)); } catch (NullPointerException e) { System.out.println("map2 threw"); } With JDK 15 the output is: > map1 threw > map2 returned false With this change I think the output will be: > map1 threw > map2 threw It seems unlikely that anyone will be bit by this, but it is a change to behavior and it wasn't called out in the Jira issue, so I felt it was worth mentioning. I think it is just this one specific case that changes -- only `Map1`, and only `entrySet().contains(null)`. Other sub-collections like `keySet()` and `values()` and `subList(...)` already throw on `contains(null)` for both the `ImmutableCollections.*` implementation and the `Collections.umodifiable*` wrapper. `MapN`'s `entrySet().contains(null)` already returns `false` for both. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From github.com+7806504+liach at openjdk.java.net Wed Feb 17 02:30:39 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 17 Feb 2021 02:30:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 23:18:55 GMT, Claes Redestad wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. > > src/java.base/share/classes/java/util/Collections.java line 1130: > >> 1128: public static Set unmodifiableSet(Set s) { >> 1129: if(s.getClass() == UnmodifiableSet.class || >> 1130: s.getClass() == ImmutableCollections.Set12.class || > > These might be problematic: `ImmutableCollections.Set*` differs in behavior subtly from `UnmodifiableSet`, e.g., `set.contains(null)` will throw an NPE. I'd limit the check and optimization to `UnmodifiableSet` here No? This unmodifiable set here just delegates call to the backing field `c`, so all exceptions from `c`'s calls are just delegated, aren't they? The NPE will still be thrown; it's just that the stack trace will be different (i.e. one more level of call in the stacktrace) ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From alanb at openjdk.java.net Wed Feb 17 07:24:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 07:24:38 GMT Subject: RFR: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 22:27:12 GMT, Mandy Chung wrote: > Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java to use ForceGC from test library which has additional instrumentation to diagnose problem. In addition, this will get the fix for JDK-8258007. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2597 From dholmes at openjdk.java.net Wed Feb 17 07:40:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 17 Feb 2021 07:40:43 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v3] In-Reply-To: <6yFge-pMXKus66tDpDNzp6QdBB_ZtLSYgDbQfM-Cm0Q=.4e9cacd4-8416-4468-8ef5-68da3f106ed8@github.com> References: <6yFge-pMXKus66tDpDNzp6QdBB_ZtLSYgDbQfM-Cm0Q=.4e9cacd4-8416-4468-8ef5-68da3f106ed8@github.com> Message-ID: On Tue, 16 Feb 2021 21:15:58 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Throw exception if exit code of child process is non-zero test/jdk/java/util/logging/FileHandlerAccessTest.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. Tests do not need, and should not have, the CPE. ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Wed Feb 17 11:50:05 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 17 Feb 2021 11:50:05 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v4] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8252883: Remove ClassPathException copyright statement ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/9472f73c..26c56c47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Wed Feb 17 11:50:06 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 17 Feb 2021 11:50:06 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v3] In-Reply-To: References: <6yFge-pMXKus66tDpDNzp6QdBB_ZtLSYgDbQfM-Cm0Q=.4e9cacd4-8416-4468-8ef5-68da3f106ed8@github.com> Message-ID: On Wed, 17 Feb 2021 07:37:42 GMT, David Holmes wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Throw exception if exit code of child process is non-zero > > test/jdk/java/util/logging/FileHandlerAccessTest.java line 9: > >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided >> 9: * by Oracle in the LICENSE file that accompanied this code. > > Tests do not need, and should not have, the CPE. Fixed, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Wed Feb 17 12:28:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 17 Feb 2021 12:28:53 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v4] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 11:50:05 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Remove ClassPathException copyright statement test/jdk/java/util/logging/FileHandlerAccessTest.java line 45: > 43: if (!(args.length == 2 || args.length == 1)) { > 44: System.out.println("Usage error: expects java FileHandlerAccessTest [process/thread] "); > 45: return; Ah - sorry - since this is a test, instead of return you should probably throw an exception - e.g.: throw new IllegalArgumentException("Usage error: expects java FileHandlerAccessTest [process/thread] "); test/jdk/java/util/logging/FileHandlerAccessTest.java line 47: > 45: return; > 46: } > 47: else if (args.length == 2) { nit: `} else if (...) {` ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From akozlov at openjdk.java.net Wed Feb 17 12:36:10 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 12:36:10 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - Merge pull request #9 from VladimirKempik/pull/2200 Removed unused variables - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=17 Stats: 2946 lines in 74 files changed: 2861 ins; 27 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 17 12:36:11 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 12:36:11 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31: > >> 29: #include "asm/assembler.inline.hpp" >> 30: #include "oops/compressedOops.hpp" >> 31: #include "runtime/vm_version.hpp" > > It's not clear why this include needed to be added. Line 448 calls `VM_Version::features()`. It seems the declaration is included indirectly somehow on the rest of the platforms, through OS specific headers. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 17 13:09:14 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 13:09:14 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster wrote: >> This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds. >> @lewurm could you comment here please > > Those values can be observed in the debugger, but aren't documented or defined in header files. > > This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether. OK, I'm going to remove this block. So we'll be able to revert changes in globals.hpp https://github.com/openjdk/jdk/pull/2200/files#r568986339 ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From akozlov at openjdk.java.net Wed Feb 17 13:11:48 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 17 Feb 2021 13:11:48 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <2DZXzH1_KDoevOmbbR0ipW0LWSo16BCilHOP1geU3_0=.201276ca-ddb3-49eb-a488-122b54467c49@github.com> On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/hotspot/share/logging/logStream.hpp line 35: > >> 33: class LogStream : public outputStream { >> 34: // see test/hotspot/gtest/logging/test_logStream.cpp >> 35: friend class LogStreamTest; > > It's not clear why this change is made for this port. This was done for previous implementation of W^X, for gtests be able to access this test. This not required anymore, this hunk was reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From jai.forums2013 at gmail.com Wed Feb 17 14:00:52 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Feb 2021 19:30:52 +0530 Subject: Comment on 8259896: Base64 MIME decoder should allow unrecognised characters within padding In-Reply-To: <7c73968d-1961-6e1f-8694-a008b3bdf551@gmail.com> References: <7c73968d-1961-6e1f-8694-a008b3bdf551@gmail.com> Message-ID: Hello Raffaello, I have added this comment from you, to that JDK-8259896 issue. -Jaikiran On 02/02/21 12:43 am, Raffaello Giulietti wrote: > Hi, > > in my opinion, the reporter of [1] is right in requiring that > extraneous characters be discarded, even inside the padding. > > Indeed, the first full paragraph on [2] reads: > > "Any characters outside of the base64 alphabet are to be ignored in > base64-encoded data." > > where "the base64 alphabet" also includes the padding character '=' > and "base64-encoded data" extends to padding as well, because padding > is an essential part of encoding. > > The legitimate doubt expressed in comment [3] should thus be solved in > favor of a bug fix. > > > My 2 cents > Greetings > Raffaello > > ---- > > [1] https://bugs.openjdk.java.net/browse/JDK-8259896 > [2] https://tools.ietf.org/html/rfc2045#page-26 > [3] > https://bugs.openjdk.java.net/browse/JDK-8259896?focusedCommentId=14395485&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14395485 > From redestad at openjdk.java.net Wed Feb 17 14:17:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 14:17:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 02:27:57 GMT, liach wrote: >> src/java.base/share/classes/java/util/Collections.java line 1130: >> >>> 1128: public static Set unmodifiableSet(Set s) { >>> 1129: if(s.getClass() == UnmodifiableSet.class || >>> 1130: s.getClass() == ImmutableCollections.Set12.class || >> >> These might be problematic: `ImmutableCollections.Set*` differs in behavior subtly from `UnmodifiableSet`, e.g., `set.contains(null)` will throw an NPE. I'd limit the check and optimization to `UnmodifiableSet` here > > No? This unmodifiable set here just delegates call to the backing field `c`, so all exceptions from `c`'s calls are just delegated, aren't they? The NPE will still be thrown; it's just that the stack trace will be different (i.e. one more level of call in the stacktrace) Yes, my bad. There might be more issues similar to the one @michaelhixson points out elsewhere in this PR, so a thorough review is probably needed here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From redestad at openjdk.java.net Wed Feb 17 14:24:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 14:24:41 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 00:30:09 GMT, Michael Hixson wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. > > src/java.base/share/classes/java/util/Collections.java line 1473: > >> 1471: public static Map unmodifiableMap(Map m) { >> 1472: if(m.getClass() == UnmodifiableMap.class || >> 1473: m.getClass() == ImmutableCollections.Map1.class || > > (I'm not a reviewer.) > > I think this causes a change in behavior to this silly program. > > var map1 = Map.of(1, 2); > var map2 = Collections.unmodifiableMap(map1); > > try { > System.out.println("map1 returned " + map1.entrySet().contains(null)); > } catch (NullPointerException e) { > System.out.println("map1 threw"); > } > > try { > System.out.println("map2 returned " + map2.entrySet().contains(null)); > } catch (NullPointerException e) { > System.out.println("map2 threw"); > } > > With JDK 15 the output is: >> map1 threw >> map2 returned false > > With this change I think the output will be: >> map1 threw >> map2 threw > > It seems unlikely that anyone will be bit by this, but it is a change to behavior and it wasn't called out in the Jira issue, so I felt it was worth mentioning. > > I think it is just this one specific case that changes -- only `Map1`, and only `entrySet().contains(null)`. Other sub-collections like `keySet()` and `values()` and `subList(...)` already throw on `contains(null)` for both the `ImmutableCollections.*` implementation and the `Collections.umodifiable*` wrapper. `MapN`'s `entrySet().contains(null)` already returns `false` for both. This sounds like an inconsistency between `Map1` and `MapN` that should perhaps be considered a bug that needs fixing. /ping @stuart-marks ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From github.com+7806504+liach at openjdk.java.net Wed Feb 17 14:41:40 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 17 Feb 2021 14:41:40 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* In-Reply-To: References: Message-ID: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> On Wed, 17 Feb 2021 14:21:37 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/util/Collections.java line 1473: >> >>> 1471: public static Map unmodifiableMap(Map m) { >>> 1472: if(m.getClass() == UnmodifiableMap.class || >>> 1473: m.getClass() == ImmutableCollections.Map1.class || >> >> (I'm not a reviewer.) >> >> I think this causes a change in behavior to this silly program. >> >> var map1 = Map.of(1, 2); >> var map2 = Collections.unmodifiableMap(map1); >> >> try { >> System.out.println("map1 returned " + map1.entrySet().contains(null)); >> } catch (NullPointerException e) { >> System.out.println("map1 threw"); >> } >> >> try { >> System.out.println("map2 returned " + map2.entrySet().contains(null)); >> } catch (NullPointerException e) { >> System.out.println("map2 threw"); >> } >> >> With JDK 15 the output is: >>> map1 threw >>> map2 returned false >> >> With this change I think the output will be: >>> map1 threw >>> map2 threw >> >> It seems unlikely that anyone will be bit by this, but it is a change to behavior and it wasn't called out in the Jira issue, so I felt it was worth mentioning. >> >> I think it is just this one specific case that changes -- only `Map1`, and only `entrySet().contains(null)`. Other sub-collections like `keySet()` and `values()` and `subList(...)` already throw on `contains(null)` for both the `ImmutableCollections.*` implementation and the `Collections.umodifiable*` wrapper. `MapN`'s `entrySet().contains(null)` already returns `false` for both. > > This sounds like an inconsistency between `Map1` and `MapN` that should perhaps be considered a bug that needs fixing. /ping @stuart-marks 2 remarks: 1. MapN's entry set extends abstract set, whose `contains` is null-friendly like https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/AbstractCollection.java#L104 2. The problem of unmodifiable map's entry set not always delegating everything to the backing entry set still exists. https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/Collections.java#L1724 This will bypass the underlying logic when the argument is `null` or not an entry. The behavior pointed out by michaelhixson is the conglomeration of these 2 unspecified behaviors. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From ewhelan at openjdk.java.net Wed Feb 17 14:47:03 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 17 Feb 2021 14:47:03 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8252883: Added IllegalArgumentException for incorrect usage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/26c56c47..b5259dcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Wed Feb 17 14:47:05 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 17 Feb 2021 14:47:05 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v4] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:24:46 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Remove ClassPathException copyright statement > > test/jdk/java/util/logging/FileHandlerAccessTest.java line 45: > >> 43: if (!(args.length == 2 || args.length == 1)) { >> 44: System.out.println("Usage error: expects java FileHandlerAccessTest [process/thread] "); >> 45: return; > > Ah - sorry - since this is a test, instead of return you should probably throw an exception - e.g.: > throw new IllegalArgumentException("Usage error: expects java FileHandlerAccessTest [process/thread] "); Done! Thanks Daniel > test/jdk/java/util/logging/FileHandlerAccessTest.java line 47: > >> 45: return; >> 46: } >> 47: else if (args.length == 2) { > > nit: `} else if (...) {` Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 14:51:52 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 14:51:52 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible Message-ID: Non-static classes hold a link to their parent classes, which in many cases can be avoided. ------------- Commit messages: - 8261880: Change nested classes in java.base to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/2589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261880 Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589 From alanb at openjdk.java.net Wed Feb 17 15:39:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 15:39:42 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 09:18:10 GMT, Philippe Marschall wrote: >> Implement three optimiztations for Reader.read(CharBuffer) >> >> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. >> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. >> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. >> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. > > Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: > > - Replace c-style array declarations > - Share work buffer between #skip and #read src/java.base/share/classes/java/io/Reader.java line 221: > 219: // if the last call to read returned -1 or the number of bytes > 220: // requested have been read then break > 221: } while (n >= 0 && remaining > 0); The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From aph at openjdk.java.net Wed Feb 17 15:55:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 17 Feb 2021 15:55:51 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik wrote: >> This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c. >> I don't understand why you think it's acceptable to bail in this case. Can you explain, please? > > it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)). > currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented. > So when a method has more argument than can be placed in registers, we may have issues. > > So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack. > > There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3 OK. I checked and the Panama preview doesn't support direct native calls for stack arguments, so we're good for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From aph at openjdk.java.net Wed Feb 17 15:55:50 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 17 Feb 2021 15:55:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com> Message-ID: <2D2djDl7sFFBYlKWrD1t7aXikT8r5iVAibMR4HI6bfw=.1465f633-0045-4917-b4dd-883f04e5e41e@github.com> On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov wrote: >> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline. > > The latest merge with JDK-8261071 should resolve the issue. Please take a look. Looks much better, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From redestad at openjdk.java.net Wed Feb 17 16:27:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 16:27:40 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: > 190: > 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ > 192: static final class Holder {} For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 16:38:04 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 16:38:04 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: > >> 190: >> 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ >> 192: static final class Holder {} > > For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. I'll just revert them ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Wed Feb 17 16:38:03 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 17 Feb 2021 16:38:03 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8261880: Remove static from declarations of Holder nested classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2589/files - new: https://git.openjdk.java.net/jdk/pull/2589/files/5650cce4..c6f9cf6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+7806504+liach at openjdk.java.net Wed Feb 17 16:38:04 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 17 Feb 2021 16:38:04 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:32:39 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192: >> >>> 190: >>> 191: /* Placeholder class for DelegatingMethodHandles generated ahead of time */ >>> 192: static final class Holder {} >> >> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not. > > I'll just revert them For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From alanb at openjdk.java.net Wed Feb 17 17:24:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 17:24:46 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman wrote: >> Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned. > >> Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible. > > The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done. > but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`? That should be okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From alanb at openjdk.java.net Wed Feb 17 17:24:46 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 17 Feb 2021 17:24:46 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 19:51:21 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert rem assertions > > Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned. > Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible. The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Wed Feb 17 17:27:56 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 17 Feb 2021 17:27:56 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:35:02 GMT, liach wrote: >> I'll just revert them > > For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From jlaskey at openjdk.java.net Wed Feb 17 17:35:09 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 17 Feb 2021 17:35:09 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v18] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Merge branch 'master' into 8248862 - Flatten out use of all() - Add review edits - Added table of available algorithms. - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - Merge branch 'master' into 8248862 - Correct range used by nextBytes - ... and 38 more: https://git.openjdk.java.net/jdk/compare/05301f5f...16f066fe ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=17 Stats: 13341 lines in 26 files changed: 11195 ins; 2055 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From mchung at openjdk.java.net Wed Feb 17 17:37:42 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 17 Feb 2021 17:37:42 GMT Subject: Integrated: 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 22:27:12 GMT, Mandy Chung wrote: > Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java to use ForceGC from test library which has additional instrumentation to diagnose problem. In addition, this will get the fix for JDK-8258007. This pull request has now been integrated. Changeset: bf75a3a0 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/bf75a3a0 Stats: 39 lines in 1 file changed: 1 ins; 37 del; 1 mod 8261851: update ReflectionCallerCacheTest.java test to use ForceGC from test library Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2597 From naoto at openjdk.java.net Wed Feb 17 17:39:00 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 17:39:00 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v4] In-Reply-To: References: Message-ID: > Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added a text about the variations from the base Unicode versions. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2538/files - new: https://git.openjdk.java.net/jdk/pull/2538/files/b94b41c8..c90cd663 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538 PR: https://git.openjdk.java.net/jdk/pull/2538 From jlaskey at openjdk.java.net Wed Feb 17 17:39:47 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 17 Feb 2021 17:39:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v17] In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 21:30:12 GMT, Andrey Turbanov wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Added table of available algorithms. > > test/jdk/java/util/Random/RandomTestBsi1999.java line 227: > >> 225: static int checkRunStats(int[] stats) { >> 226: int runFailure = 0; >> 227: runFailure |= ((2267 <= stats[1]) || (stats[1] <= 2733)) ? 0 : 1; > > 1. confusing formatting. > 2. This condition is always `true`. Looks like `&&` should be used instead of `||` Correct. Changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+828220+forax at openjdk.java.net Wed Feb 17 17:44:47 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 17 Feb 2021 17:44:47 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:24:50 GMT, Claes Redestad wrote: >> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors. > > Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9. Inner classes doesn't really exist for the JVM, it's just an attribute (in fact, a pair of attributes) that is read/write by javac (it's very similar to the way generics work). So it is Ok to have static methods in inner classes since Java 1.1 from the JVM POV with the caveat that you may not be all to call them from Java-the-language. Also since Java 11, inner classes are also nestmate and those attributes (NestHost/NestMembers) change the behavior of the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From igraves at openjdk.java.net Wed Feb 17 17:47:07 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 17 Feb 2021 17:47:07 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v2] In-Reply-To: References: Message-ID: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: If-block formatting ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2596/files - new: https://git.openjdk.java.net/jdk/pull/2596/files/e0a06bf7..53e366a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596 From igraves at openjdk.java.net Wed Feb 17 18:27:44 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 17 Feb 2021 18:27:44 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v2] In-Reply-To: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> References: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> Message-ID: On Wed, 17 Feb 2021 14:37:52 GMT, liach wrote: >> This sounds like an inconsistency between `Map1` and `MapN` that should perhaps be considered a bug that needs fixing. /ping @stuart-marks > > 2 remarks: > 1. MapN's entry set extends abstract set, whose `contains` is null-friendly like https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/AbstractCollection.java#L104 > 2. The problem of unmodifiable map's entry set not always delegating everything to the backing entry set still exists. https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/Collections.java#L1724 This will bypass the underlying logic when the argument is `null` or not an entry. > > The behavior pointed out by michaelhixson is the conglomeration of these 2 unspecified behaviors. This raises some interesting issues and makes me wonder if we should allow a single-wrap of the `ImmutableCollections` classes for now to make this less onerous. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From darcy at openjdk.java.net Wed Feb 17 18:46:42 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 17 Feb 2021 18:46:42 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v4] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:39:00 GMT, Naoto Sato wrote: >> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added a text about the variations from the base Unicode versions. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From igraves at openjdk.java.net Wed Feb 17 19:14:38 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 17 Feb 2021 19:14:38 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v2] In-Reply-To: References: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> Message-ID: On Wed, 17 Feb 2021 18:24:39 GMT, Ian Graves wrote: >> 2 remarks: >> 1. MapN's entry set extends abstract set, whose `contains` is null-friendly like https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/AbstractCollection.java#L104 >> 2. The problem of unmodifiable map's entry set not always delegating everything to the backing entry set still exists. https://github.com/openjdk/jdk/blob/cb84539d56209a6687c4ec71a61fdbe6f06a46ea/src/java.base/share/classes/java/util/Collections.java#L1724 This will bypass the underlying logic when the argument is `null` or not an entry. >> >> The behavior pointed out by michaelhixson is the conglomeration of these 2 unspecified behaviors. > > This raises some interesting issues and makes me wonder if we should allow a single-wrap of the `ImmutableCollections` classes for now to make this less onerous. Yes -- I think in response to this it makes more sense to pull the `ImmutableCollections` classes out for now and only focus on the wrapping of the classes within `Collections` so we aren't blocked by studying and rectifying these inconsistencies. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From naoto at openjdk.java.net Wed Feb 17 19:39:50 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 19:39:50 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter Message-ID: Please review this simple doc fix. A CSR will be filed accordingly. ------------- Commit messages: - 8261728: SimpleDateFormat should link to DateTimeFormatter Changes: https://git.openjdk.java.net/jdk/pull/2616/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261728 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2616.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2616/head:pull/2616 PR: https://git.openjdk.java.net/jdk/pull/2616 From bpb at openjdk.java.net Wed Feb 17 19:48:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 19:48:38 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. LGTM ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2616 From attila at openjdk.java.net Wed Feb 17 19:53:50 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Wed, 17 Feb 2021 19:53:50 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Message-ID: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" ------------- Commit messages: - 8261483: Try to eliminate flakiness of the test by extending its allowed runtime and reducing the memory Changes: https://git.openjdk.java.net/jdk/pull/2617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261483 Stats: 6 lines in 3 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2617/head:pull/2617 PR: https://git.openjdk.java.net/jdk/pull/2617 From igraves at openjdk.java.net Wed Feb 17 19:56:01 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 17 Feb 2021 19:56:01 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v3] In-Reply-To: References: Message-ID: <84e4oda9As0m5jPdm1EcQOry30jgGHUaj0TUaYc26Fs=.7468ee66-2f76-43df-9b0f-16e9082b3b6d@github.com> > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing ImmutableCollections.* idempotency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2596/files - new: https://git.openjdk.java.net/jdk/pull/2596/files/53e366a9..a9588e9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=01-02 Stats: 38 lines in 2 files changed: 7 ins; 17 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596 From rriggs at openjdk.java.net Wed Feb 17 20:07:39 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 17 Feb 2021 20:07:39 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From lancea at openjdk.java.net Wed Feb 17 20:07:39 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 17 Feb 2021 20:07:39 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter In-Reply-To: References: Message-ID: <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com> On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. Hi Naoto, Looks good. Any thoughts to making the new wording stick out more perhaps via a something like "Note: Consider...." and bolding "Note:" Not sure if it is @apiNote worthy but I guess that is an option also? ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2616 From igraves at openjdk.java.net Wed Feb 17 20:20:40 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 17 Feb 2021 20:20:40 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v3] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 14:14:57 GMT, Claes Redestad wrote: >> No? This unmodifiable set here just delegates call to the backing field `c`, so all exceptions from `c`'s calls are just delegated, aren't they? The NPE will still be thrown; it's just that the stack trace will be different (i.e. one more level of call in the stacktrace) > > Yes, my bad. There might be more issues similar to the one @michaelhixson points out elsewhere in this PR, so a thorough review is probably needed here. Resolving these for now. Going to punt these inconsistencies to another bug before bringing this back in. This change will focus on the idempotency of these methods vs. the classes contained in `Collections`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From naoto at openjdk.java.net Wed Feb 17 20:21:57 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 20:21:57 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: References: Message-ID: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> > Please review this simple doc fix. A CSR will be filed accordingly. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Made the additional text an @apiNote ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2616/files - new: https://git.openjdk.java.net/jdk/pull/2616/files/d840b562..c93badb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2616&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2616&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2616.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2616/head:pull/2616 PR: https://git.openjdk.java.net/jdk/pull/2616 From bpb at openjdk.java.net Wed Feb 17 20:21:58 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 20:21:58 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> References: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> Message-ID: On Wed, 17 Feb 2021 20:18:56 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Made the additional text an @apiNote Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From naoto at openjdk.java.net Wed Feb 17 20:21:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 20:21:59 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com> References: <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com> Message-ID: On Wed, 17 Feb 2021 20:04:33 GMT, Lance Andersen wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Made the additional text an @apiNote > > Hi Naoto, > > Looks good. > > Any thoughts to making the new wording stick out more perhaps via a something like "Note: Consider...." and bolding "Note:" > > > Not sure if it is @apiNote worthy but I guess that is an option also? > Not sure if it is @APinote worthy but I guess that is an option also? Good point. Modified. ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From lancea at openjdk.java.net Wed Feb 17 20:21:58 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 17 Feb 2021 20:21:58 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> References: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> Message-ID: On Wed, 17 Feb 2021 20:18:56 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Made the additional text an @apiNote Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From bpb at openjdk.java.net Wed Feb 17 21:55:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 21:55:52 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance Message-ID: Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. ------------- Commit messages: - 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance Changes: https://git.openjdk.java.net/jdk/pull/2618/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6245663 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2618/head:pull/2618 PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Wed Feb 17 22:12:06 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 22:12:06 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: References: Message-ID: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> > Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6245663: Mention 'dest' parameter in the added doc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2618/files - new: https://git.openjdk.java.net/jdk/pull/2618/files/a8e2cb1e..43e46a38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2618/head:pull/2618 PR: https://git.openjdk.java.net/jdk/pull/2618 From rriggs at openjdk.java.net Wed Feb 17 22:12:08 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 17 Feb 2021 22:12:08 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: <_4vAd0UxFAQS_O291tzj8TAlEnKtP6HZSf8szFARG-Y=.668848c8-d3e0-4460-abe0-aa9904dfdebf@github.com> On Wed, 17 Feb 2021 22:08:47 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Mention 'dest' parameter in the added doc src/java.base/share/classes/java/io/File.java line 1383: > 1381: * object does not itself change although the filesystem object it denoted > 1382: * might have moved. > 1383: * Is there a way to mix in a mention of the {@ code "dest"} argument. "might have moved to the abstract pathname provided in the dest argument". ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Wed Feb 17 22:12:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 22:12:08 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <_4vAd0UxFAQS_O291tzj8TAlEnKtP6HZSf8szFARG-Y=.668848c8-d3e0-4460-abe0-aa9904dfdebf@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> <_4vAd0UxFAQS_O291tzj8TAlEnKtP6HZSf8szFARG-Y=.668848c8-d3e0-4460-abe0-aa9904dfdebf@github.com> Message-ID: On Wed, 17 Feb 2021 22:04:38 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 6245663: Mention 'dest' parameter in the added doc > > src/java.base/share/classes/java/io/File.java line 1383: > >> 1381: * object does not itself change although the filesystem object it denoted >> 1382: * might have moved. >> 1383: * > > Is there a way to mix in a mention of the {@ code "dest"} argument. > "might have moved to the abstract pathname provided in the dest argument". Good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From naoto at openjdk.java.net Wed Feb 17 22:13:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 22:13:40 GMT Subject: Integrated: 8261621: Delegate Unicode history from JLS to j.l.Character In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 02:50:35 GMT, Naoto Sato wrote: > Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly. This pull request has now been integrated. Changeset: ea5bf45c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/ea5bf45c Stats: 38 lines in 1 file changed: 36 ins; 0 del; 2 mod 8261621: Delegate Unicode history from JLS to j.l.Character Reviewed-by: bpb, joehw, rriggs, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From naoto at openjdk.java.net Wed Feb 17 22:27:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 22:27:40 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: On Wed, 17 Feb 2021 22:12:06 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Mention 'dest' parameter in the added doc src/java.base/share/classes/java/io/File.java line 1381: > 1379: * that the rename operation was successful. As instances of {@code File} > 1380: * are immutable, the abstract pathname represented by this {@code File} > 1381: * object does not itself change although the filesystem object it denoted I guess you meant `file` object here, instead of `filesystem`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Wed Feb 17 22:31:45 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 22:31:45 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: On Wed, 17 Feb 2021 22:24:53 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 6245663: Mention 'dest' parameter in the added doc > > src/java.base/share/classes/java/io/File.java line 1381: > >> 1379: * that the rename operation was successful. As instances of {@code File} >> 1380: * are immutable, the abstract pathname represented by this {@code File} >> 1381: * object does not itself change although the filesystem object it denoted > > I guess you meant `file` object here, instead of `filesystem`? No, I intended `filesystem` but in the sense of "object in the filesystem" but it does seem awkward. ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From rriggs at openjdk.java.net Wed Feb 17 22:57:40 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 17 Feb 2021 22:57:40 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: On Wed, 17 Feb 2021 22:12:06 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Mention 'dest' parameter in the added doc Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Wed Feb 17 23:10:57 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Feb 2021 23:10:57 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v3] In-Reply-To: References: Message-ID: > Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6245663: Update copyright year. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2618/files - new: https://git.openjdk.java.net/jdk/pull/2618/files/43e46a38..e7ff82d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2618/head:pull/2618 PR: https://git.openjdk.java.net/jdk/pull/2618 From naoto at openjdk.java.net Wed Feb 17 23:17:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 17 Feb 2021 23:17:41 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v3] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 23:10:57 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Update copyright year. Thanks. Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2618 From iris at openjdk.java.net Thu Feb 18 00:07:41 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 18 Feb 2021 00:07:41 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> References: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> Message-ID: On Wed, 17 Feb 2021 20:21:57 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Made the additional text an @apiNote Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From jiefu at openjdk.java.net Thu Feb 18 02:33:58 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 18 Feb 2021 02:33:58 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block Message-ID: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Hi all, ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning ------------- Commit messages: - 8261938: ASN1Formatter.annotate should not return in the finally block Changes: https://git.openjdk.java.net/jdk/pull/2620/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2620&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261938 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2620.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2620/head:pull/2620 PR: https://git.openjdk.java.net/jdk/pull/2620 From jiefu at openjdk.java.net Thu Feb 18 02:46:53 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 18 Feb 2021 02:46:53 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v2] In-Reply-To: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: > Hi all, > > ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. > But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. > > Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 > [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 > [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Update the copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2620/files - new: https://git.openjdk.java.net/jdk/pull/2620/files/c0af12b1..b537e060 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2620&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2620&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2620.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2620/head:pull/2620 PR: https://git.openjdk.java.net/jdk/pull/2620 From dholmes at openjdk.java.net Thu Feb 18 03:59:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Feb 2021 03:59:41 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> References: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> Message-ID: <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com> On Fri, 12 Feb 2021 15:22:15 GMT, Roger Riggs wrote: > > > The table is informative and should not be construed as specification. > The wording "has supported" should be sufficient. If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification? ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From darcy at openjdk.java.net Thu Feb 18 06:08:52 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 18 Feb 2021 06:08:52 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc Message-ID: Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. ------------- Commit messages: - 8261940: Fix references to IOException in BigDecimal javadoc Changes: https://git.openjdk.java.net/jdk/pull/2623/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2623&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261940 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2623/head:pull/2623 PR: https://git.openjdk.java.net/jdk/pull/2623 From github.com+741251+turbanoff at openjdk.java.net Thu Feb 18 07:15:40 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 18 Feb 2021 07:15:40 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? > https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 > https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Thu Feb 18 08:31:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Feb 2021 08:31:38 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 06:03:41 GMT, Joe Darcy wrote: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. Looks okay but it might be simpler to just import java.io.IOException and avoid having two usages of the fully qualified name in the source file. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2623 From alanb at openjdk.java.net Thu Feb 18 09:26:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Feb 2021 09:26:39 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: On Wed, 17 Feb 2021 22:28:11 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/File.java line 1381: >> >>> 1379: * that the rename operation was successful. As instances of {@code File} >>> 1380: * are immutable, the abstract pathname represented by this {@code File} >>> 1381: * object does not itself change although the filesystem object it denoted >> >> I guess you meant `file` object here, instead of `filesystem`? > > No, I intended `filesystem` but in the sense of "object in the filesystem" but it does seem awkward. It might be clearer if the end of the sentence were changed to something like "... this File object is not changed to name destination file or directory". ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From chegar at openjdk.java.net Thu Feb 18 09:26:39 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 18 Feb 2021 09:26:39 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 06:03:41 GMT, Joe Darcy wrote: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2623 From jboes at openjdk.java.net Thu Feb 18 10:38:41 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 18 Feb 2021 10:38:41 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: <8pRy5JBdXXoJzu35O6aFHAUALWZ__OBbdganHZKu1FE=.f5fcf42b-eab5-49a6-9450-4942c933f39d@github.com> On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? To re-integrate, just run the /integrate command again. Before doing that, could someone from security libs acknowledge the changes in their area? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From dfuchs at openjdk.java.net Thu Feb 18 10:43:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 18 Feb 2021 10:43:40 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 14:47:03 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Added IllegalArgumentException for incorrect usage LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2572 From chegar at openjdk.java.net Thu Feb 18 11:54:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 18 Feb 2021 11:54:40 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: <8erqBs2u14oRGdt-KmCGy9IGLZnv5k1tqwm57BSnjBQ=.4e8133b8-f287-43a0-94d3-da136336e56b@github.com> On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes The changes in java/net look ok to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 18 14:35:48 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 18 Feb 2021 14:35:48 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings Message-ID: Hello, as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: String delimiter = this.delimiter; char[] chars = new char[this.len + addLen]; int k = getChars(this.prefix, chars, 0); if (size > 0) { k += getChars(elts[0], chars, k); // inflate byte[] for(int i = 1; i < size; ++i) { k += getChars(delimiter, chars, k); k += getChars(elts[i], chars, k); } } k += getChars(this.suffix, chars, k); return new String(chars); // compress char[] -> byte[] This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) covering both cases when resulting String is Latin1 or UTF-16 I've prepared a patch along with benchmark proving that this change is correct and brings improvement. @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class StringJoinerBenchmark { @Benchmark public String stringJoiner(Data data) { String[] stringArray = data.stringArray; return Joiner.joinWithStringJoiner(stringArray); } @State(Scope.Thread) public static class Data { @Param({"latin", "cyrillic", "mixed"}) private String mode; @Param({"8", "32", "64"}) private int length; @Param({"5", "10", "100"}) private int count; private String[] stringArray; @Setup public void setup() { RandomStringGenerator generator = new RandomStringGenerator(); stringArray = new String[count]; for (int i = 0; i < count; i++) { String alphabet = getAlphabet(i, mode); stringArray[i] = generator.randomString(alphabet, length); } } private static String getAlphabet(int index, String mode) { var latin = "abcdefghijklmnopqrstuvwxyz"; //English var cyrillic = "????????????????????????????????"; // Russian String alphabet; switch (mode) { case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; case "latin" -> alphabet = latin; case "cyrillic" -> alphabet = cyrillic; default -> throw new RuntimeException("Illegal mode " + mode); } return alphabet; } } } (count) (length) (mode) Java 14 patched Units stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op ------------- Commit messages: - 8261880: Check also delimiter, prefix and suffix - 8148937: (str) Adapt StringJoiner for Compact Strings Changes: https://git.openjdk.java.net/jdk/pull/2627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8148937 Stats: 77 lines in 3 files changed: 56 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627 PR: https://git.openjdk.java.net/jdk/pull/2627 From rriggs at openjdk.java.net Thu Feb 18 14:51:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 18 Feb 2021 14:51:46 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com> References: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com> Message-ID: On Thu, 18 Feb 2021 03:56:49 GMT, David Holmes wrote: >> The table is informative and should not be construed as specification. >> The wording "has supported" should be sufficient. > >> >> >> The table is informative and should not be construed as specification. >> The wording "has supported" should be sufficient. > > If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification? The current version of Unicode is specified in a normative statement just before the table. "Character information is based on the Unicode Standard, version 13.0." The table is not a specification of past revisions. ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From rriggs at openjdk.java.net Thu Feb 18 14:55:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 18 Feb 2021 14:55:47 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v2] In-Reply-To: References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: On Thu, 18 Feb 2021 02:46:53 GMT, Jie Fu wrote: >> Hi all, >> >> ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. >> But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. >> >> Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 >> [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 >> [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Update the copyright year An EOFException can occur during the call to annotate() and must return the accumulated contents of the StringBuffer. Otherwise it is discarded. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2620 From rriggs at openjdk.java.net Thu Feb 18 14:57:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 18 Feb 2021 14:57:41 GMT Subject: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2] In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> References: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com> Message-ID: On Wed, 17 Feb 2021 20:21:57 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Made the additional text an @apiNote Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From redestad at openjdk.java.net Thu Feb 18 15:22:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Feb 2021 15:22:39 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 14:30:15 GMT, ?????? ??????? wrote: > Hello, > > as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. > > This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. > > As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: > String delimiter = this.delimiter; > char[] chars = new char[this.len + addLen]; > int k = getChars(this.prefix, chars, 0); > if (size > 0) { > k += getChars(elts[0], chars, k); // inflate byte[] > > for(int i = 1; i < size; ++i) { > k += getChars(delimiter, chars, k); > k += getChars(elts[i], chars, k); > } > } > > k += getChars(this.suffix, chars, k); > return new String(chars); // compress char[] -> byte[] > This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) > covering both cases when resulting String is Latin1 or UTF-16 > > I've prepared a patch along with benchmark proving that this change is correct and brings improvement. > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class StringJoinerBenchmark { > > @Benchmark > public String stringJoiner(Data data) { > String[] stringArray = data.stringArray; > return Joiner.joinWithStringJoiner(stringArray); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"latin", "cyrillic", "mixed"}) > private String mode; > > @Param({"8", "32", "64"}) > private int length; > > @Param({"5", "10", "100"}) > private int count; > > private String[] stringArray; > > @Setup > public void setup() { > RandomStringGenerator generator = new RandomStringGenerator(); > > stringArray = new String[count]; > > for (int i = 0; i < count; i++) { > String alphabet = getAlphabet(i, mode); > stringArray[i] = generator.randomString(alphabet, length); > } > } > > private static String getAlphabet(int index, String mode) { > var latin = "abcdefghijklmnopqrstuvwxyz"; //English > var cyrillic = "????????????????????????????????"; // Russian > > String alphabet; > switch (mode) { > case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; > case "latin" -> alphabet = latin; > case "cyrillic" -> alphabet = cyrillic; > default -> throw new RuntimeException("Illegal mode " + mode); > } > return alphabet; > } > } > } > > > (count) (length) (mode) Java 14 patched Units > stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op > stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op > stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op > stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op > stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op > stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op > stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op > stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op > stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op > stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op > stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op > stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op > stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op > stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op > stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op > stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op > stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op > stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op > stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op > stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op > stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op > stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op > stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op > stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op > stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op > stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op > stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op > > stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op > stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op > stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op > stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op > stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op > stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From jlaskey at openjdk.java.net Thu Feb 18 15:29:01 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Feb 2021 15:29:01 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v19] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits: - Merge branch 'master' into 8248862 - Update tests for RandomGeneratorFactory.all() - Merge branch 'master' into 8248862 - Flatten out use of all() - Add review edits - Added table of available algorithms. - Merge branch 'master' into 8248862 - Update SplittableRandom to remove unnecessary overrides - Updated API based on CSR review. - Update package info to credit LMX algorithm - ... and 40 more: https://git.openjdk.java.net/jdk/compare/f94a8452...7d0ebfc9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=18 Stats: 13341 lines in 26 files changed: 11195 ins; 2055 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Thu Feb 18 16:24:00 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 18 Feb 2021 16:24:00 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v20] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct copyright notice. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/7d0ebfc9..9861b4e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=18-19 Stats: 28 lines in 1 file changed: 6 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From iris at openjdk.java.net Thu Feb 18 16:44:39 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 18 Feb 2021 16:44:39 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc In-Reply-To: References: Message-ID: <1rCIuPB8tArqqS8gVcuh6ItLF1aXYq2AK39win0-YVE=.ee8ff427-8525-4474-a256-c12945e2b657@github.com> On Thu, 18 Feb 2021 06:03:41 GMT, Joe Darcy wrote: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2623 From bpb at openjdk.java.net Thu Feb 18 16:45:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Feb 2021 16:45:41 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> Message-ID: <49pCgWNZRRhwsVJv3wayrX9fDJoamhi9qxKx9QnFt7k=.bc35e365-bbc6-4c34-ba3e-a41810d3f330@github.com> On Thu, 18 Feb 2021 09:24:06 GMT, Alan Bateman wrote: >> No, I intended `filesystem` but in the sense of "object in the filesystem" but it does seem awkward. > > It might be clearer if the end of the sentence were changed to something like "... this File object is not changed to name destination file or directory". Like so? --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -1376,7 +1376,9 @@ public class File * file from one filesystem to another, it might not be atomic, and it * might not succeed if a file with the destination abstract pathname * already exists. The return value should always be checked to make sure - * that the rename operation was successful. + * that the rename operation was successful. As instances of {@code File} + * are immutable, this File object is not changed to name the destination + * file or directory. * *

      Note that the {@link java.nio.file.Files} class defines the {@link * java.nio.file.Files#move move} method to move or rename a file in a ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Thu Feb 18 16:54:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Feb 2021 16:54:40 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 06:03:41 GMT, Joe Darcy wrote: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. I concur with @AlanBateman about importing `IOException`. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2623 From alanb at openjdk.java.net Thu Feb 18 17:02:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Feb 2021 17:02:39 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <49pCgWNZRRhwsVJv3wayrX9fDJoamhi9qxKx9QnFt7k=.bc35e365-bbc6-4c34-ba3e-a41810d3f330@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> <49pCgWNZRRhwsVJv3wayrX9fDJoamhi9qxKx9QnFt7k=.bc35e365-bbc6-4c34-ba3e-a41810d3f330@github.com> Message-ID: <_pS6_q0o7JNUFkqUDZEt7-Cd7POOvbEMRv-SA97EYpM=.6197cb49-ac14-4ff6-88be-69f16933ab09@github.com> On Thu, 18 Feb 2021 16:43:09 GMT, Brian Burkhalter wrote: >> It might be clearer if the end of the sentence were changed to something like "... this File object is not changed to name destination file or directory". > > Like so? > --- a/src/java.base/share/classes/java/io/File.java > +++ b/src/java.base/share/classes/java/io/File.java > @@ -1376,7 +1376,9 @@ public class File > * file from one filesystem to another, it might not be atomic, and it > * might not succeed if a file with the destination abstract pathname > * already exists. The return value should always be checked to make sure > - * that the rename operation was successful. > + * that the rename operation was successful. As instances of {@code File} > + * are immutable, this File object is not changed to name the destination > + * file or directory. > * > *

      Note that the {@link java.nio.file.Files} class defines the {@link > * java.nio.file.Files#move move} method to move or rename a file in a yes, I think that works. ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From loikeseke at gmail.com Thu Feb 18 17:20:45 2021 From: loikeseke at gmail.com (=?UTF-8?Q?Lo=C3=AFc_MATHIEU?=) Date: Thu, 18 Feb 2021 18:20:45 +0100 Subject: System.getEnv(String name, String def) In-Reply-To: <694130485.1268749.1613509153830.JavaMail.zimbra@u-pem.fr> References: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> <1b208826-6371-e623-5321-f7586b9358cd@fiolino.de> <694130485.1268749.1613509153830.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, Thanks for your replies. My point here was that using env variables is more and more common to configure apps, and they have less convenient support than system properties (the other way to provide easy external configuration at launch time with key/value). I agree that Objects.requireNonNullElse(System.getEnv(String key), "n/a")); is an easy way to achieve this, but I still think System.getEnv(key, "n/a") should be a good addition. Regards, Lo?c Le mar. 16 f?vr. 2021 ? 21:59, Remi Forax a ?crit : > ----- Mail original ----- > > De: "Michael Kuhlmann" > > ?: "core-libs-dev" > > Envoy?: Mardi 16 F?vrier 2021 13:34:30 > > Objet: Re: System.getEnv(String name, String def) > > > Hi R?mi, > > > > I don't want to be pedantic, but I see this as an anti-pattern. You > > would create an Optional just to immediately call orElse() on it. That's > > not how Optional should be used. (But you know that.) > > > > It's described in Recipe 12 of this Java Magazine article, for instance: > > > https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used > > yep, you are right. > Optional.ofNullable(...).orElse(...) is not the best pattern in term of > readability. > > > > > Best, > > Michael > > regards, > R?mi > > > > > On 2/15/21 3:09 PM, Remi Forax wrote: > >> Hi Loic, > >> You can use Optional.OfNullable() which is a kind of the general bridge > between > >> the nullable world and the non-nullable one. > >> > >> var fooOptional = Optional.ofNullable(System.getenv("FOO")); > >> var fooValue = fooOptional.orElse(defaultValue); > >> > >> regards, > >> R?mi Forax > >> > >> ----- Mail original ----- > >>> De: "Lo?c MATHIEU" > >>> ?: "core-libs-dev" > >>> Envoy?: Lundi 15 F?vrier 2021 14:59:42 > >>> Objet: System.getEnv(String name, String def) > >> > >>> Hello, > >>> > >>> I wonder if there has already been some discussion to provide > >>> a System.getEnv(String name, String def) method that allows to return a > >>> default value in case the env variable didn't exist. > >>> > >>> When using system properties instead of env variable, we do have a > >>> System.getProperty(String key, String def) variant. > >>> > >>> Stating the JavaDoc of System.getEnv(): > >>> *System properties and environment variables are both conceptually > mappings > >>> between names and values* > >>> > >>> So if system properties and environment variables are similar concepts, > >>> they should provide the same functionalities right ? > >>> > >>> This would be very convenient as more and more people rely on > >>> environment variables these days to configure their applications. > >>> > >>> Regards, > >>> > > >> Lo?c > From bpb at openjdk.java.net Thu Feb 18 17:34:04 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Feb 2021 17:34:04 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v4] In-Reply-To: References: Message-ID: > Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6245663: Simplify new verbiage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2618/files - new: https://git.openjdk.java.net/jdk/pull/2618/files/e7ff82d2..e6a23ab4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2618&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2618/head:pull/2618 PR: https://git.openjdk.java.net/jdk/pull/2618 From bpb at openjdk.java.net Thu Feb 18 17:36:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Feb 2021 17:36:39 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v2] In-Reply-To: <_pS6_q0o7JNUFkqUDZEt7-Cd7POOvbEMRv-SA97EYpM=.6197cb49-ac14-4ff6-88be-69f16933ab09@github.com> References: <9gQGJ5w0jwsxh8Q-DtE2yGhj4lwKhf87-TfSKG9Mm38=.e186bb64-695d-4b9e-856a-5e78e35911aa@github.com> <49pCgWNZRRhwsVJv3wayrX9fDJoamhi9qxKx9QnFt7k=.bc35e365-bbc6-4c34-ba3e-a41810d3f330@github.com> <_pS6_q0o7JNUFkqUDZEt7-Cd7POOvbEMRv-SA97EYpM=.6197cb49-ac14-4ff6-88be-69f16933ab09@github.com> Message-ID: <1Rk2pw3kgBb3B08A_g0nVxFP-xn3rQcWX3uXyFxNz0I=.25e74975-045b-4cc0-8ca3-9141150263c9@github.com> On Thu, 18 Feb 2021 16:59:54 GMT, Alan Bateman wrote: >> Like so? >> --- a/src/java.base/share/classes/java/io/File.java >> +++ b/src/java.base/share/classes/java/io/File.java >> @@ -1376,7 +1376,9 @@ public class File >> * file from one filesystem to another, it might not be atomic, and it >> * might not succeed if a file with the destination abstract pathname >> * already exists. The return value should always be checked to make sure >> - * that the rename operation was successful. >> + * that the rename operation was successful. As instances of {@code File} >> + * are immutable, this File object is not changed to name the destination >> + * file or directory. >> * >> *

      Note that the {@link java.nio.file.Files} class defines the {@link >> * java.nio.file.Files#move move} method to move or rename a file in a > > yes, I think that works. [CSR](https://bugs.openjdk.java.net/browse/JDK-8261935) also so updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From darcy at openjdk.java.net Thu Feb 18 17:55:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 18 Feb 2021 17:55:59 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc [v2] In-Reply-To: References: Message-ID: <0HRhcmY0-UHNyVYNxQbLPPyaGTY1N0afntQ--nbBxDQ=.57812345-1b36-493f-8768-1210ffb9cfb9@github.com> On Thu, 18 Feb 2021 16:52:19 GMT, Brian Burkhalter wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > I concur with @AlanBateman about importing `IOException`. Will integrate using the suggested import of java.io.IOException; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2623 From darcy at openjdk.java.net Thu Feb 18 17:55:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 18 Feb 2021 17:55:59 GMT Subject: RFR: 8261940: Fix references to IOException in BigDecimal javadoc [v2] In-Reply-To: References: Message-ID: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. 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/2623/files - new: https://git.openjdk.java.net/jdk/pull/2623/files/27ff1d78..e3a1659f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2623&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2623&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2623.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2623/head:pull/2623 PR: https://git.openjdk.java.net/jdk/pull/2623 From darcy at openjdk.java.net Thu Feb 18 17:56:00 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 18 Feb 2021 17:56:00 GMT Subject: Integrated: 8261940: Fix references to IOException in BigDecimal javadoc In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 06:03:41 GMT, Joe Darcy wrote: > Noticed by some of Jon Gibbons's doc linting & checking tooling, this changeset fixes two javadoc issues for BigDecimal's serialization-related methods, improving the serial form page. This pull request has now been integrated. Changeset: c4664e64 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c4664e64 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8261940: Fix references to IOException in BigDecimal javadoc Reviewed-by: alanb, chegar, iris, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2623 From alanb at openjdk.java.net Thu Feb 18 18:08:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Feb 2021 18:08:40 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v4] In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 17:34:04 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Simplify new verbiage Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From rriggs at openjdk.java.net Thu Feb 18 19:04:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 18 Feb 2021 19:04:42 GMT Subject: RFR: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance [v4] In-Reply-To: References: Message-ID: <5gKiXlSceLAEiWSF9tfnrZjtC-a_VQpDQ9oUjtQWG_E=.234baba3-bc27-45ee-a81b-d93c92ffb86d@github.com> On Thu, 18 Feb 2021 17:34:04 GMT, Brian Burkhalter wrote: >> Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6245663: Simplify new verbiage Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From mullan at openjdk.java.net Thu Feb 18 19:24:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 18 Feb 2021 19:24:43 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: Message-ID: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo > remove unnecessary file.exists() check src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: > 226: try { > 227: if (is.markSupported() == false) { > 228: // Copy the entire input stream into an InputStream that does I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From attila at openjdk.java.net Thu Feb 18 19:31:02 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 18 Feb 2021 19:31:02 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8261483: Try to eliminate flakiness of the test by extending its allowed runtime and reducing the memory ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2617/files - new: https://git.openjdk.java.net/jdk/pull/2617/files/989dfb64..3afec32b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=00-01 Stats: 20 lines in 2 files changed: 5 ins; 8 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2617/head:pull/2617 PR: https://git.openjdk.java.net/jdk/pull/2617 From asemenyuk at openjdk.java.net Thu Feb 18 19:39:44 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 18 Feb 2021 19:39:44 GMT Subject: RFR: 8261977: Fix comment for getPrefixed() in canonicalize_md.c Message-ID: Follow up for JDK-8235397 fix ------------- Commit messages: - Fix comment for getPrefixed() in canonicalize_md.c Changes: https://git.openjdk.java.net/jdk/pull/2631/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261977 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2631/head:pull/2631 PR: https://git.openjdk.java.net/jdk/pull/2631 From attila at openjdk.java.net Thu Feb 18 19:43:39 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Thu, 18 Feb 2021 19:43:39 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 19:44:35 GMT, Attila Szegedi wrote: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" @plevart can I bother you for a follow-up review of my original issue? (Alternatively, @shipilev?) Unfortunately the tests as I wrote them are flaking on somewhat loaded CI servers. Shame on me for using timing-based tests? Thanks for the consideration. I changed the flaky tests to use an upper limit on number of iterations instead of a maximum duration, so they won't be time sensitive anymore. I'm also running them with a separate VM using a very small max heap (4M) so the GC condition triggers quickly. Finally, I measured the number of iterations they need to succeed with this heap size; the numbers are deterministic across executions, but I also added a generous padding (least iterations needed by a test is 30, most needed is 219, I'm allowing the tests to run until 5000.) ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From alanb at openjdk.java.net Thu Feb 18 19:52:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Feb 2021 19:52:40 GMT Subject: RFR: 8261977: Fix comment for getPrefixed() in canonicalize_md.c In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 19:35:09 GMT, Alexey Semenyuk wrote: > Follow up for JDK-8235397 fix Thanks for this, it means we can move this code to the right place in the future. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2631 From github.com+471021+marschall at openjdk.java.net Thu Feb 18 20:01:44 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Thu, 18 Feb 2021 20:01:44 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:22:21 GMT, Alan Bateman wrote: >>> Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible. >> >> The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done. > >> but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`? > > That should be okay. > > > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well? > > > > > > Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE. > > Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617 > > It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication. My understanding was ISO_8859_1$Encoder.implEncodeISOArray and StringUTF16.compress are ultimately hooked up to the same intrinsic. I find it inconsistent that ISO_8859_1$Encoder access an encoding intrinsitc directly while ISO_8859_1$Decoder and others access a decoding intrinsic indirectly through JavaLangAccess. I realize this RFE is about decoding so keeping encoding to a different RFE may indeed be better. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 18 20:16:39 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 18 Feb 2021 20:16:39 GMT Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 15:19:43 GMT, Claes Redestad wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols. >> >> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called: >> String delimiter = this.delimiter; >> char[] chars = new char[this.len + addLen]; >> int k = getChars(this.prefix, chars, 0); >> if (size > 0) { >> k += getChars(elts[0], chars, k); // inflate byte[] >> >> for(int i = 1; i < size; ++i) { >> k += getChars(delimiter, chars, k); >> k += getChars(elts[i], chars, k); >> } >> } >> >> k += getChars(this.suffix, chars, k); >> return new String(chars); // compress char[] -> byte[] >> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082) >> covering both cases when resulting String is Latin1 or UTF-16 >> >> I've prepared a patch along with benchmark proving that this change is correct and brings improvement. >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) >> public class StringJoinerBenchmark { >> >> @Benchmark >> public String stringJoiner(Data data) { >> String[] stringArray = data.stringArray; >> return Joiner.joinWithStringJoiner(stringArray); >> } >> >> @State(Scope.Thread) >> public static class Data { >> >> @Param({"latin", "cyrillic", "mixed"}) >> private String mode; >> >> @Param({"8", "32", "64"}) >> private int length; >> >> @Param({"5", "10", "100"}) >> private int count; >> >> private String[] stringArray; >> >> @Setup >> public void setup() { >> RandomStringGenerator generator = new RandomStringGenerator(); >> >> stringArray = new String[count]; >> >> for (int i = 0; i < count; i++) { >> String alphabet = getAlphabet(i, mode); >> stringArray[i] = generator.randomString(alphabet, length); >> } >> } >> >> private static String getAlphabet(int index, String mode) { >> var latin = "abcdefghijklmnopqrstuvwxyz"; //English >> var cyrillic = "????????????????????????????????"; // Russian >> >> String alphabet; >> switch (mode) { >> case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin; >> case "latin" -> alphabet = latin; >> case "cyrillic" -> alphabet = cyrillic; >> default -> throw new RuntimeException("Illegal mode " + mode); >> } >> return alphabet; >> } >> } >> } >> >> >> (count) (length) (mode) Java 14 patched Units >> stringJoiner 5 8 latin 78.836 ? 0.208 67.546 ? 0.500 ns/op >> stringJoiner 5 32 latin 92.877 ? 0.422 66.760 ? 0.498 ns/op >> stringJoiner 5 64 latin 115.423 ? 0.883 73.224 ? 0.289 ns/op >> stringJoiner 10 8 latin 152.587 ? 0.429 161.427 ? 0.635 ns/op >> stringJoiner 10 32 latin 189.998 ? 0.478 164.099 ? 0.963 ns/op >> stringJoiner 10 64 latin 238.679 ? 1.419 176.825 ? 0.533 ns/op >> stringJoiner 100 8 latin 1215.612 ? 17.413 1541.802 ? 126.166 ns/op >> stringJoiner 100 32 latin 1699.998 ? 28.407 1563.341 ? 4.439 ns/op >> stringJoiner 100 64 latin 2289.388 ? 45.319 2215.931 ? 137.583 ns/op >> stringJoiner 5 8 cyrillic 96.692 ? 0.947 80.946 ? 0.371 ns/op >> stringJoiner 5 32 cyrillic 107.806 ? 0.429 84.717 ? 0.541 ns/op >> stringJoiner 5 64 cyrillic 150.762 ? 2.267 96.214 ? 1.251 ns/op >> stringJoiner 10 8 cyrillic 190.570 ? 0.381 182.754 ? 0.678 ns/op >> stringJoiner 10 32 cyrillic 240.239 ? 1.110 187.991 ? 1.575 ns/op >> stringJoiner 10 64 cyrillic 382.493 ? 2.692 219.358 ? 0.967 ns/op >> stringJoiner 100 8 cyrillic 1737.435 ? 16.171 1658.379 ? 56.225 ns/op >> stringJoiner 100 32 cyrillic 2321.106 ? 13.583 1942.028 ? 3.418 ns/op >> stringJoiner 100 64 cyrillic 3189.563 ? 10.135 2484.796 ? 7.572 ns/op >> stringJoiner 5 8 mixed 88.743 ? 0.709 76.049 ? 0.685 ns/op >> stringJoiner 5 32 mixed 103.425 ? 0.745 81.006 ? 0.184 ns/op >> stringJoiner 5 64 mixed 146.441 ? 0.763 93.071 ? 0.858 ns/op >> stringJoiner 10 8 mixed 169.262 ? 0.482 158.890 ? 0.598 ns/op >> stringJoiner 10 32 mixed 218.566 ? 0.945 170.415 ? 1.172 ns/op >> stringJoiner 10 64 mixed 361.412 ? 1.546 200.374 ? 0.683 ns/op >> stringJoiner 100 8 mixed 1594.544 ? 5.761 1476.689 ? 2.004 ns/op >> stringJoiner 100 32 mixed 2221.333 ? 28.320 1879.071 ? 52.729 ns/op >> stringJoiner 100 64 mixed 3115.786 ? 22.485 2400.644 ? 4.401 ns/op >> >> stringJoiner:?gc.alloc.rate.norm 5 8 latin 248.023 ? 0.001 136.015 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 latin 608.045 ? 0.001 256.022 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 latin 1088.067 ? 0.002 416.030 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 latin 464.044 ? 0.001 264.029 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 latin 1184.085 ? 0.003 504.044 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 latin 2144.123 ? 0.005 824.065 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 latin 3872.367 ? 8.002 2024.269 ? 8.016 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 latin 11048.803 ? 7.988 4416.393 ? 0.004 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 latin 20657.194 ? 9.775 7640.642 ? 9.819 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 cyrillic 360.029 ? 0.001 184.020 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 cyrillic 960.060 ? 0.002 424.032 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 cyrillic 1760.088 ? 0.003 744.043 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 cyrillic 664.063 ? 0.001 352.038 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 cyrillic 1864.128 ? 0.003 832.067 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 cyrillic 3464.206 ? 0.007 1472.094 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 cyrillic 5704.541 ? 0.006 2928.317 ? 8.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 cyrillic 17705.090 ? 0.045 7720.658 ? 0.007 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 cyrillic 33689.855 ? 9.786 14121.042 ? 0.015 B/op >> stringJoiner:?gc.alloc.rate.norm 5 8 mixed 360.028 ? 0.001 184.016 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 32 mixed 960.059 ? 0.002 424.031 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 5 64 mixed 1760.088 ? 0.003 744.041 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 8 mixed 664.052 ? 0.001 352.035 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 10 32 mixed 1864.116 ? 0.005 832.064 ? 0.001 B/op >> stringJoiner:?gc.alloc.rate.norm 10 64 mixed 3464.196 ? 0.006 1472.088 ? 0.002 B/op >> stringJoiner:?gc.alloc.rate.norm 100 8 mixed 5672.448 ? 8.002 2920.314 ? 0.006 B/op >> stringJoiner:?gc.alloc.rate.norm 100 32 mixed 17681.092 ? 9.824 7728.653 ? 8.008 B/op >> stringJoiner:?gc.alloc.rate.norm 100 64 mixed 33697.818 ? 8.011 14120.977 ? 0.034 B/op > > Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. > > As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. Hi @cl4es, > Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing public boolean isLatin1(String str) { return str.isLatin1(); } with public boolean isLatin1(String str) { return str.coder == String.LATIN1; } The rest of the code was left intact. `jdk:tier1` is OK after the change. > As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang. Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities? ------------- PR: https://git.openjdk.java.net/jdk/pull/2627 From github.com+471021+marschall at openjdk.java.net Thu Feb 18 20:19:40 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Thu, 18 Feb 2021 20:19:40 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 15:37:11 GMT, Alan Bateman wrote: >> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace c-style array declarations >> - Share work buffer between #skip and #read > > src/java.base/share/classes/java/io/Reader.java line 221: > >> 219: // if the last call to read returned -1 or the number of bytes >> 220: // requested have been read then break >> 221: } while (n >= 0 && remaining > 0); > > The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder. Right. So you propose to revert the off-heap path to the current master? That would be fine with me. The original bug and my motivation was only about the backing array case, the rest crept in. That would certainly keep the risk and impact lower. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From bpb at openjdk.java.net Thu Feb 18 20:38:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Feb 2021 20:38:43 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 15:37:11 GMT, Alan Bateman wrote: >> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace c-style array declarations >> - Share work buffer between #skip and #read > > src/java.base/share/classes/java/io/Reader.java line 221: > >> 219: // if the last call to read returned -1 or the number of bytes >> 220: // requested have been read then break >> 221: } while (n >= 0 && remaining > 0); > > The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder. I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From asemenyuk at openjdk.java.net Thu Feb 18 20:57:41 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 18 Feb 2021 20:57:41 GMT Subject: Integrated: 8261977: Fix comment for getPrefixed() in canonicalize_md.c In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 19:35:09 GMT, Alexey Semenyuk wrote: > Follow up for JDK-8235397 fix This pull request has now been integrated. Changeset: 0c31d5b9 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/0c31d5b9 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8261977: Fix comment for getPrefixed() in canonicalize_md.c Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2631 From redestad at openjdk.java.net Thu Feb 18 23:16:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Feb 2021 23:16:00 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v4] In-Reply-To: References: Message-ID: > This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. > > - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. > - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting > - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert JavaLangAccessImpl changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2574/files - new: https://git.openjdk.java.net/jdk/pull/2574/files/367be2a5..e2316007 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=02-03 Stats: 176 lines in 2 files changed: 6 ins; 10 del; 160 mod Patch: https://git.openjdk.java.net/jdk/pull/2574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574 PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Thu Feb 18 23:19:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 18 Feb 2021 23:19:39 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman wrote: > > Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible. > > The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done. Turns out the native code called by `SystemProps.initProperties();` can initialize a `CharsetDecoder` if `sun.jnu.encoding` is set to certain values, and this tripped up the initialization to cause `getJavaLangAccess` to be called before `setJavaLangAccess`. By moving `setJavaLangAccess` to the very start of `initPhase1` we avoid this possibility, and limit churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From jiefu at openjdk.java.net Thu Feb 18 23:43:39 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 18 Feb 2021 23:43:39 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v2] In-Reply-To: References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: On Thu, 18 Feb 2021 14:53:17 GMT, Roger Riggs wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the copyright year > > An EOFException can occur during the call to annotate() and must return the accumulated contents of the StringBuffer. Otherwise it is discarded. Thanks @RogerRiggs for your review. Just want to make sure: 1. AFAIK, for a method, it seems impossible to return a value and throw an exception at the same time. Did you mean we just need to return a string with the IOException to be catched? 2. Does it make sense to return a string when an IOException happens? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2620 From github.com+28367473+jmehrens at openjdk.java.net Fri Feb 19 00:10:39 2021 From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens) Date: Fri, 19 Feb 2021 00:10:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v3] In-Reply-To: References: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> Message-ID: On Wed, 17 Feb 2021 19:12:19 GMT, Ian Graves wrote: >> This raises some interesting issues and makes me wonder if we should allow a single-wrap of the `ImmutableCollections` classes for now to make this less onerous. > > Yes -- I think in response to this it makes more sense to pull the `ImmutableCollections` classes out for now and only focus on the wrapping of the classes within `Collections` so we aren't blocked by studying and rectifying these inconsistencies. Maybe it is not correct for UnmodifiableEntrySet::contains to short circuit? What if the implementation was changed to: `public boolean contains(Object o) { if (!(o instanceof Map.Entry)) return c.contains(o); //false, NPE, or CCE return c.contains( new UnmodifiableEntry<>((Map.Entry) o)); }` ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From emcmanus at google.com Fri Feb 19 01:45:29 2021 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Thu, 18 Feb 2021 17:45:29 -0800 Subject: System.getEnv(String name, String def) In-Reply-To: References: <1905682243.371082.1613398160785.JavaMail.zimbra@u-pem.fr> <1b208826-6371-e623-5321-f7586b9358cd@fiolino.de> <694130485.1268749.1613509153830.JavaMail.zimbra@u-pem.fr> Message-ID: I think System.getenv().getOrDefault(key, def) is already an adequate solution. On Thu, 18 Feb 2021 at 09:21, Lo?c MATHIEU wrote: > Hi, > > Thanks for your replies. > > My point here was that using env variables is more and more common to > configure apps, and they have less convenient support than system > properties (the other way to provide easy external configuration at launch > time with key/value). > > I agree that Objects.requireNonNullElse(System.getEnv(String key), "n/a")); > is an easy way to achieve this, but I still think System.getEnv(key, "n/a") > should be a good addition. > > Regards, > > Lo?c > > Le mar. 16 f?vr. 2021 ? 21:59, Remi Forax a ?crit : > > > ----- Mail original ----- > > > De: "Michael Kuhlmann" > > > ?: "core-libs-dev" > > > Envoy?: Mardi 16 F?vrier 2021 13:34:30 > > > Objet: Re: System.getEnv(String name, String def) > > > > > Hi R?mi, > > > > > > I don't want to be pedantic, but I see this as an anti-pattern. You > > > would create an Optional just to immediately call orElse() on it. > That's > > > not how Optional should be used. (But you know that.) > > > > > > It's described in Recipe 12 of this Java Magazine article, for > instance: > > > > > > https://blogs.oracle.com/javamagazine/12-recipes-for-using-the-optional-class-as-its-meant-to-be-used > > > > yep, you are right. > > Optional.ofNullable(...).orElse(...) is not the best pattern in term of > > readability. > > > > > > > > Best, > > > Michael > > > > regards, > > R?mi > > > > > > > > On 2/15/21 3:09 PM, Remi Forax wrote: > > >> Hi Loic, > > >> You can use Optional.OfNullable() which is a kind of the general > bridge > > between > > >> the nullable world and the non-nullable one. > > >> > > >> var fooOptional = Optional.ofNullable(System.getenv("FOO")); > > >> var fooValue = fooOptional.orElse(defaultValue); > > >> > > >> regards, > > >> R?mi Forax > > >> > > >> ----- Mail original ----- > > >>> De: "Lo?c MATHIEU" > > >>> ?: "core-libs-dev" > > >>> Envoy?: Lundi 15 F?vrier 2021 14:59:42 > > >>> Objet: System.getEnv(String name, String def) > > >> > > >>> Hello, > > >>> > > >>> I wonder if there has already been some discussion to provide > > >>> a System.getEnv(String name, String def) method that allows to > return a > > >>> default value in case the env variable didn't exist. > > >>> > > >>> When using system properties instead of env variable, we do have a > > >>> System.getProperty(String key, String def) variant. > > >>> > > >>> Stating the JavaDoc of System.getEnv(): > > >>> *System properties and environment variables are both conceptually > > mappings > > >>> between names and values* > > >>> > > >>> So if system properties and environment variables are similar > concepts, > > >>> they should provide the same functionalities right ? > > >>> > > >>> This would be very convenient as more and more people rely on > > >>> environment variables these days to configure their applications. > > >>> > > >>> Regards, > > >>> > > > >> Lo?c > > > From github.com+7806504+liach at openjdk.java.net Fri Feb 19 01:55:40 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Fri, 19 Feb 2021 01:55:40 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v3] In-Reply-To: References: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> Message-ID: On Thu, 18 Feb 2021 16:18:42 GMT, jmehrens wrote: >> Yes -- I think in response to this it makes more sense to pull the `ImmutableCollections` classes out for now and only focus on the wrapping of the classes within `Collections` so we aren't blocked by studying and rectifying these inconsistencies. > > Maybe it is not correct for UnmodifiableEntrySet::contains to short circuit? What if the implementation was changed to: > > `public boolean contains(Object o) { > if (!(o instanceof Map.Entry)) > return c.contains(o); //false, NPE, or CCE > return c.contains( > new UnmodifiableEntry<>((Map.Entry) o)); > }` This however changes the behavior of unmodifiable maps compared to before; i.e. before for other entry sets, they could not throw exception if the object passed was not map entry; now they can. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From rriggs at openjdk.java.net Fri Feb 19 01:58:39 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Feb 2021 01:58:39 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v2] In-Reply-To: References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: <9BduPNFNWI8mXNm57LsZRvGTF3AbZgKtd8tzjNotLRc=.52e8b0ce-9094-41bd-96cf-fea77cc95b37@github.com> On Thu, 18 Feb 2021 23:41:08 GMT, Jie Fu wrote: >> An EOFException can occur during the call to annotate() and must return the accumulated contents of the StringBuffer. Otherwise it is discarded. > > Thanks @RogerRiggs for your review. > > Just want to make sure: > > 1. AFAIK, for a method, it seems impossible to return a value and throw an exception at the same time. > Did you mean we just need to return a string with the IOException to be catched? > > 2. Does it make sense to return a string when an IOException happens? > > Thanks. The formattters are a test component used both standalone and in the context of the HexPrinter test utilities. In typical use, the stream is a wrapped byte array, so there are no exceptions other than EOF. The choice of DataInputStream was chosen for the convenience of the methods to read different types and (declared) exceptions are an unwelcome artifact. Formatters are designed to be nested, where one formatter can call another and the valuable output is the formatted string that has been accumulated from the beginning of the stream. If an exception was percolated up and the formatted output discarded it would defeat the purpose. If an exception was thrown, it would still return useful information about the stream to that point. The documentation could be improved to be clear on that point. ------------- PR: https://git.openjdk.java.net/jdk/pull/2620 From jiefu at openjdk.java.net Fri Feb 19 03:36:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 19 Feb 2021 03:36:00 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v3] In-Reply-To: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: > Hi all, > > ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. > But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. > > Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 > [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 > [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Catch exception and return the accumulated string ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2620/files - new: https://git.openjdk.java.net/jdk/pull/2620/files/b537e060..a1f29f33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2620&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2620&range=01-02 Stats: 16 lines in 1 file changed: 13 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2620.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2620/head:pull/2620 PR: https://git.openjdk.java.net/jdk/pull/2620 From jiefu at openjdk.java.net Fri Feb 19 03:38:38 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 19 Feb 2021 03:38:38 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v2] In-Reply-To: <9BduPNFNWI8mXNm57LsZRvGTF3AbZgKtd8tzjNotLRc=.52e8b0ce-9094-41bd-96cf-fea77cc95b37@github.com> References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> <9BduPNFNWI8mXNm57LsZRvGTF3AbZgKtd8tzjNotLRc=.52e8b0ce-9094-41bd-96cf-fea77cc95b37@github.com> Message-ID: On Fri, 19 Feb 2021 01:56:19 GMT, Roger Riggs wrote: > The formattters are a test component used both standalone and in the context of the HexPrinter test utilities. > In typical use, the stream is a wrapped byte array, so there are no exceptions other than EOF. > The choice of DataInputStream was chosen for the convenience of the methods to read different types > and (declared) exceptions are an unwelcome artifact. > > Formatters are designed to be nested, where one formatter can call another and the valuable output > is the formatted string that has been accumulated from the beginning of the stream. > If an exception was percolated up and the formatted output discarded it would defeat the purpose. > > If an exception was thrown, it would still return useful information about the stream to that point. > The documentation could be improved to be clear on that point. Got it. Thanks for your clarification. Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2620 From joehw at openjdk.java.net Fri Feb 19 06:37:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 19 Feb 2021 06:37:39 GMT Subject: Integrated: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer In-Reply-To: References: Message-ID: On Sat, 13 Feb 2021 00:16:50 GMT, Joe Wang wrote: > Adds a property similar to 'isStandalone' in JDK-8249867. > > Please note that the test received an auto-format. The material changes were the two tests marked with bug id 8260858 and related data and methods. This pull request has now been integrated. Changeset: c99eeb01 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/c99eeb01 Stats: 243 lines in 7 files changed: 167 ins; 4 del; 72 mod 8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2559 From alanb at openjdk.java.net Fri Feb 19 07:37:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Feb 2021 07:37:38 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 20:35:10 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 221: >> >>> 219: // if the last call to read returned -1 or the number of bytes >>> 220: // requested have been read then break >>> 221: } while (n >= 0 && remaining > 0); >> >> The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder. > > I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks. Yes, let's keep bring it back to just eliminating the intermediate array when the buffer has a backing array. The other case that been examined separated if needed but we can't use the approach proposed in the current PR because it changes the semantics of read when there is a short-read followed by a blocking or exception throwing read. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From alanb at openjdk.java.net Fri Feb 19 07:49:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Feb 2021 07:49:51 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v2] In-Reply-To: References: Message-ID: <8oM8c_hWCz1dgpCmRg_8eATS1MwlcsleJ7pATWhDYIM=.0af21dc5-d548-4355-bf71-c2cb5ccc9fc3@github.com> On Thu, 18 Feb 2021 23:16:54 GMT, Claes Redestad wrote: > Turns out the native code called by `SystemProps.initProperties();` can initialize a `CharsetDecoder` if `sun.jnu.encoding` is set to certain values, and this tripped up the initialization to cause `getJavaLangAccess` to be called before `setJavaLangAccess`. By moving `setJavaLangAccess` to the very start of `initPhase1` we avoid this possibility, and limit churn. I assume this is tests running with -Dfile.encoding. I can go along with moving setJavaLangAccess to the start of initPhase1. I'll do another pass over the updated patch today. Good work! ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From github.com+741251+turbanoff at openjdk.java.net Fri Feb 19 08:07:42 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 19 Feb 2021 08:07:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo >> remove unnecessary file.exists() check > > src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: > >> 226: try { >> 227: if (is.markSupported() == false) { >> 228: // Copy the entire input stream into an InputStream that does > > I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); private static List parsePKCS7(InputStream is) certs = parsePKCS7(is); public X509CertPath(InputStream is, String encoding) return new X509CertPath(new ByteArrayInputStream(data), encoding); PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); private static List parsePKCS7(InputStream is) certs = parsePKCS7(is); public X509CertPath(InputStream is, String encoding) this(is, PKIPATH_ENCODING); public X509CertPath(InputStream is) throws CertificateException { return new X509CertPath(new ByteArrayInputStream(encoding)); ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) Perhaps original marking approach was lost during refactoring? ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From jboes at openjdk.java.net Fri Feb 19 10:19:54 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Fri, 19 Feb 2021 10:19:54 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass Message-ID: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. Testing: tier 1-3 all clear. ------------- Commit messages: - remove superfluous boxing Changes: https://git.openjdk.java.net/jdk/pull/2641/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2641&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248318 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2641.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2641/head:pull/2641 PR: https://git.openjdk.java.net/jdk/pull/2641 From jlaskey at openjdk.java.net Fri Feb 19 11:25:48 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 19 Feb 2021 11:25:48 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2641 From plevart at openjdk.java.net Fri Feb 19 11:25:54 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 19 Feb 2021 11:25:54 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 19:41:21 GMT, Attila Szegedi wrote: >> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" > > @plevart can I bother you for a follow-up review of my original issue? (Alternatively, @shipilev?) Unfortunately the tests as I wrote them are flaking on somewhat loaded CI servers. Shame on me for using timing-based tests? Thanks for the consideration. > > I changed the flaky tests to use an upper limit on number of iterations instead of a maximum duration, so they won't be time sensitive anymore. I'm also running them with a separate VM using a very small max heap (4M) so the GC condition triggers quickly. Finally, I measured the number of iterations they need to succeed with this heap size; the numbers are deterministic across executions, but I also added a generous padding (least iterations needed by a test is 30, most needed is 219, I'm allowing the tests to run until 5000.) > Unfortunately the tests as I wrote them are flaking on somewhat loaded CI servers... > > I changed the flaky tests to use an upper limit on number of iterations instead of a maximum duration, so they won't be time sensitive anymore. I'm also running them with a separate VM using a very small max heap (4M) so the GC condition triggers quickly. Finally, I measured the number of iterations they need to succeed with this heap size; the numbers are deterministic across executions, but I also added a generous padding (least iterations needed by a test is 30, most needed is 219, I'm allowing the tests to run until 5000.) I played a little with TypeConverterFactoryMemoryLeakTest. If I add `System.gc()` call and a 10ms sleep into the loop, the test succeeds after 12 iterations even if I increase the heap size considerably. I would like 1st to understand why the MH created in the TestLinker.convertToType is actually GCed at all. And after that, why it is not GCed before 12 invocations to makeOne() are made. What would be more interesting to test is to create a converter between a type loaded by a custom (child) ClassLoader and a system type. After that, release all hard references to the custom ClassLoader and see if the converter gets GC-ed as a result. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From github.com+4410404+vyommani at openjdk.java.net Fri Feb 19 11:25:50 2021 From: github.com+4410404+vyommani at openjdk.java.net (Vyom Mani Tewari) Date: Fri, 19 Feb 2021 11:25:50 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. Looks ok to me. ------------- Marked as reviewed by vyommani at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/2641 From clanger at openjdk.java.net Fri Feb 19 11:29:01 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 19 Feb 2021 11:29:01 GMT Subject: RFR: 8262018: Wrong format in SAP copyright header of OsVersionTest Message-ID: The fix for JDK-8261753 introduced a ',' after the copyright years which is not the expected format for SAP copyrights. ------------- Commit messages: - JDK-8262018 Changes: https://git.openjdk.java.net/jdk/pull/2642/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2642&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262018 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2642.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2642/head:pull/2642 PR: https://git.openjdk.java.net/jdk/pull/2642 From mdoerr at openjdk.java.net Fri Feb 19 11:29:01 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 19 Feb 2021 11:29:01 GMT Subject: RFR: 8262018: Wrong format in SAP copyright header of OsVersionTest In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 10:35:21 GMT, Christoph Langer wrote: > The fix for JDK-8261753 introduced a ',' after the copyright years which is not the expected format for SAP copyrights. Seems like this is the only place where we have the wrong comma. Looks good and trivial. Thanks for fixing! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2642 From jlaskey at openjdk.java.net Fri Feb 19 12:48:05 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 19 Feb 2021 12:48:05 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove tabs from random/package-info.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/9861b4e4..cfaf7cef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=19-20 Stats: 102 lines in 1 file changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Fri Feb 19 13:00:44 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 19 Feb 2021 13:00:44 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com> References: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com> Message-ID: On Wed, 25 Nov 2020 13:55:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGenerator.java line 745: >> >>> 743: * if the period is unknown. >>> 744: */ >>> 745: BigInteger UNKNOWN_PERIOD = BigInteger.ZERO; >> >> move those 3 values into RandomGeneratorFactory ? > > Will ponder on this one. I tend to agree with you since they are most likely to be used for filtering factories RandomGeneratorFactory querying was a later development. period() originally was a RandomGenerator query, but got moved when more queries were added. This will require a CSR and will come later. Now unused and removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From dfuchs at openjdk.java.net Fri Feb 19 13:28:39 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 19 Feb 2021 13:28:39 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: <-Sggvwh4kRQ8JlcWORQUP-avtvdOAYaDvrIfRFr00qU=.ca0a973f-90a7-433f-b605-71e172d8cee9@github.com> On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. LGTM. Please add a `noreg-cleanup` label to the JBS issue. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2641 From naoto at openjdk.java.net Fri Feb 19 14:00:18 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Feb 2021 14:00:18 GMT Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com> Message-ID: On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs wrote: >>> >>> >>> The table is informative and should not be construed as specification. >>> The wording "has supported" should be sufficient. >> >> If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification? > > The current version of Unicode is specified in a normative statement just before the table. > "Character information is based on the Unicode Standard, version 13.0." > > The table is not a specification of past revisions. RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released. ------------- PR: https://git.openjdk.java.net/jdk/pull/2538 From dfuchs at openjdk.java.net Fri Feb 19 14:10:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 19 Feb 2021 14:10:16 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: Message-ID: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> On Thu, 18 Feb 2021 10:41:17 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Added IllegalArgumentException for incorrect usage > > LGTM I'm seeing some intermittent test failures with the new test (after merging in latest master changes). Can you retest and have a look: ----------System.out:(25/1343)---------- Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Testing with arguments: type=process, count=20 Thread-2 |Error: Could not find or load main class FileHandlerAccessTest Thread-2 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest Thread-6 |Error: Could not find or load main class FileHandlerAccessTest Thread-6 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest Thread-1 |Error: Could not find or load main class FileHandlerAccessTest Thread-1 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest Testing with arguments: type=process, count=20 ----------System.err:(14/1024)---------- java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.RuntimeException: An error occured in the child process. at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) ... 1 more STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.RuntimeException: An error occured in the child process. at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) ... 1 more STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. ----------rerun:(39/6191)*---------- ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From alanb at openjdk.java.net Fri Feb 19 14:19:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Feb 2021 14:19:41 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v4] In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad wrote: >> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. >> >> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. >> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting >> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert JavaLangAccessImpl changes Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From naoto at openjdk.java.net Fri Feb 19 14:27:42 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Feb 2021 14:27:42 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v4] In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad wrote: >> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. >> >> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. >> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting >> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert JavaLangAccessImpl changes Marked as reviewed by naoto (Reviewer). src/java.base/share/classes/java/lang/System.java line 1988: > 1986: // might initialize CharsetDecoders that rely on it > 1987: setJavaLangAccess(); > 1988: Good to see the init issue has been resolved with a simple reordering. ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From clanger at openjdk.java.net Fri Feb 19 14:50:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 19 Feb 2021 14:50:40 GMT Subject: Integrated: 8262018: Wrong format in SAP copyright header of OsVersionTest In-Reply-To: References: Message-ID: <9XPYtE7zLh7s1o2RF8P7fBmVmWFl2uKog2sLrr8wuj8=.599bafff-16ce-4b13-936a-6947ac43c83d@github.com> On Fri, 19 Feb 2021 10:35:21 GMT, Christoph Langer wrote: > The fix for JDK-8261753 introduced a ',' after the copyright years which is not the expected format for SAP copyrights. This pull request has now been integrated. Changeset: efbaedeb Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/efbaedeb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8262018: Wrong format in SAP copyright header of OsVersionTest Reviewed-by: mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/2642 From rriggs at openjdk.java.net Fri Feb 19 15:02:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Feb 2021 15:02:46 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2641 From mullan at openjdk.java.net Fri Feb 19 15:05:42 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 19 Feb 2021 15:05:42 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228: >> >>> 226: try { >>> 227: if (is.markSupported() == false) { >>> 228: // Copy the entire input stream into an InputStream that does >> >> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is. > > As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); > private static List parsePKCS7(InputStream is) > certs = parsePKCS7(is); > public X509CertPath(InputStream is, String encoding) > return new X509CertPath(new ByteArrayInputStream(data), encoding); > > PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); > private static List parsePKCS7(InputStream is) > certs = parsePKCS7(is); > public X509CertPath(InputStream is, String encoding) > this(is, PKIPATH_ENCODING); > public X509CertPath(InputStream is) throws CertificateException { > return new X509CertPath(new ByteArrayInputStream(encoding)); > > ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) > > Perhaps original marking approach was lost during refactoring? You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later. [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6 ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From redestad at openjdk.java.net Fri Feb 19 15:08:43 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Feb 2021 15:08:43 GMT Subject: Integrated: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad wrote: > This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations. > > - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. > - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting > - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 433096a4 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/433096a4 Stats: 557 lines in 13 files changed: 296 ins; 106 del; 155 mod 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From redestad at openjdk.java.net Fri Feb 19 15:08:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Feb 2021 15:08:41 GMT Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths [v4] In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 14:24:34 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert JavaLangAccessImpl changes > > Marked as reviewed by naoto (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/2574 From rriggs at openjdk.java.net Fri Feb 19 15:17:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Feb 2021 15:17:41 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v3] In-Reply-To: References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: On Fri, 19 Feb 2021 03:36:00 GMT, Jie Fu wrote: >> Hi all, >> >> ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. >> But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. >> >> Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 >> [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 >> [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Catch exception and return the accumulated string Catching and ignoring the exception has the same behavior as handling it with finally. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2620 From bpb at openjdk.java.net Fri Feb 19 16:38:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Feb 2021 16:38:40 GMT Subject: Integrated: 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 21:48:16 GMT, Brian Burkhalter wrote: > Please review this minor specification update to highlight that `File.renameTo(File)` does not modify the `File` instance on which the method is invoked. This pull request has now been integrated. Changeset: 851b2e31 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/851b2e31 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 6245663: (spec) File.renameTo(File) changes the file-system object, not the File instance Reviewed-by: rriggs, naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2618 From chegar at openjdk.java.net Fri Feb 19 16:46:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 19 Feb 2021 16:46:40 GMT Subject: RFR: 8248318: Examine the use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. LGTM. Optionally (and trivially), you could update the JIRA description, from "Examine" to "Remove superfluous use of ..." ( or some such ) ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2641 From naoto at openjdk.java.net Fri Feb 19 16:47:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Feb 2021 16:47:41 GMT Subject: Integrated: 8261728: SimpleDateFormat should link to DateTimeFormatter In-Reply-To: References: Message-ID: <3Oe9KvrW3YQktepmERb0V4JuOQs-mWHBeecVELn3cH4=.4987bf1c-6eba-4afa-ad10-b10d5b380940@github.com> On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. This pull request has now been integrated. Changeset: 8a1c712c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8a1c712c Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod 8261728: SimpleDateFormat should link to DateTimeFormatter Reviewed-by: bpb, rriggs, lancea, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/2616 From rriggs at openjdk.java.net Fri Feb 19 16:49:41 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Feb 2021 16:49:41 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v3] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 17:25:00 GMT, Brian Burkhalter wrote: >> Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8247918: Remove verbiage describing impossible behavior in CharArrayReader and StringReader Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From dcubed at openjdk.java.net Fri Feb 19 17:01:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Feb 2021 17:01:02 GMT Subject: RFR: 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows Message-ID: A trivial fix to ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows. ------------- Commit messages: - 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows Changes: https://git.openjdk.java.net/jdk/pull/2650/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262042 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2650/head:pull/2650 PR: https://git.openjdk.java.net/jdk/pull/2650 From naoto at openjdk.java.net Fri Feb 19 17:14:43 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Feb 2021 17:14:43 GMT Subject: RFR: 8247918: Clarify Reader.skip behavior for end of stream [v3] In-Reply-To: References: Message-ID: On Fri, 12 Feb 2021 17:25:00 GMT, Brian Burkhalter wrote: >> Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8247918: Remove verbiage describing impossible behavior in CharArrayReader and StringReader Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From dcubed at openjdk.java.net Fri Feb 19 17:14:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Feb 2021 17:14:39 GMT Subject: RFR: 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows In-Reply-To: References: Message-ID: <1xzxgHdLv7uJs7kjw6zhdModPRw80wBAh8B8DrZuPWQ=.462e8106-a70b-484f-9186-fa037b094d05@github.com> On Fri, 19 Feb 2021 16:52:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows. @JoeWang-Java - Can you please review this ProblemListing? That will allow us to reduce the noise in Tier2 and give you time to analyze the Win* failure mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/2650 From bpb at openjdk.java.net Fri Feb 19 17:24:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Feb 2021 17:24:41 GMT Subject: Integrated: 8247918: Clarify Reader.skip behavior for end of stream In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:22:55 GMT, Brian Burkhalter wrote: > Please review this clarification of the specification of the method `skip(long)` in `java.io.Reader` and its subclasses. Specifically, the behavior of the method is made clear for the case when the `Reader` is already at the end of its stream when the method is invoked. A corresponding CSR will be filed. Also, the change includes an update to an existing test in order to verify that the specification change reflects actual behavior. This pull request has now been integrated. Changeset: 7ffa1481 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/7ffa1481 Stats: 138 lines in 8 files changed: 69 ins; 30 del; 39 mod 8247918: Clarify Reader.skip behavior for end of stream Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2274 From dcubed at openjdk.java.net Fri Feb 19 17:33:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Feb 2021 17:33:41 GMT Subject: RFR: 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows In-Reply-To: References: Message-ID: <3Mz9GlWkU-UK7b9JxeZ8VMrnKQLNvzRe8o-0NogQdsE=.237185be-cecd-42ed-800f-c3f60e16feea@github.com> On Fri, 19 Feb 2021 17:29:42 GMT, Joe Wang wrote: >> A trivial fix to ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows. > > Marked as reviewed by joehw (Reviewer). @JoeWang-Java - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2650 From joehw at openjdk.java.net Fri Feb 19 17:33:41 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 19 Feb 2021 17:33:41 GMT Subject: RFR: 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 16:52:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2650 From dcubed at openjdk.java.net Fri Feb 19 17:33:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Feb 2021 17:33:42 GMT Subject: Integrated: 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 16:52:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows. This pull request has now been integrated. Changeset: 8b4fd77f Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/8b4fd77f Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8262042: ProblemList javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java on Windows Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/2650 From isipka at openjdk.java.net Fri Feb 19 18:34:55 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Fri, 19 Feb 2021 18:34:55 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v5] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 22:09:33 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - 8166026: Refactor java/lang shell tests to java >> - 8166026: Refactor java/lang shell tests to java >> - 8166026: Refactor java/lang shell tests to java >> - 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/annotation/LoaderLeakTest.java line 78: > >> 76: // URL classes = new URL("file://" + System.getProperty("user.dir") + "/classes"); >> 77: // URL[] path = { classes }; >> 78: // URLClassLoader loader = new URLClassLoader(path); > > please remove the commented out lines (L76-78) That indentation is intended to make the code more readable, at least I find it so. Changed now to more "traditional style". ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From joehw at openjdk.java.net Fri Feb 19 22:17:55 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 19 Feb 2021 22:17:55 GMT Subject: RFR: 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 Message-ID: A quick fix to the test, removing Windows carriage return in the result. ------------- Commit messages: - 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 Changes: https://git.openjdk.java.net/jdk/pull/2656/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2656&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262041 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2656/head:pull/2656 PR: https://git.openjdk.java.net/jdk/pull/2656 From lancea at openjdk.java.net Fri Feb 19 22:28:39 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 19 Feb 2021 22:28:39 GMT Subject: RFR: 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 22:12:35 GMT, Joe Wang wrote: > A quick fix to the test, removing Windows carriage return in the result. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2656 From naoto at openjdk.java.net Fri Feb 19 23:10:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 19 Feb 2021 23:10:40 GMT Subject: RFR: 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 22:12:35 GMT, Joe Wang wrote: > A quick fix to the test, removing Windows carriage return in the result. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2656 From jiefu at openjdk.java.net Fri Feb 19 23:48:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 19 Feb 2021 23:48:40 GMT Subject: RFR: 8261938: ASN1Formatter.annotate should not return in the finally block [v3] In-Reply-To: References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: On Fri, 19 Feb 2021 15:15:05 GMT, Roger Riggs wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Catch exception and return the accumulated string > > Catching and ignoring the exception has the same behavior as handling it with finally. Thanks @RogerRiggs . ------------- PR: https://git.openjdk.java.net/jdk/pull/2620 From jiefu at openjdk.java.net Fri Feb 19 23:48:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 19 Feb 2021 23:48:40 GMT Subject: Integrated: 8261938: ASN1Formatter.annotate should not return in the finally block In-Reply-To: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> References: <1beHFzdpg7T5VS1tr7a8oOustBxOh3l-Y8_XEliaTGI=.d99c4c1b-92b1-423e-8d93-d67a7c2a62ad@github.com> Message-ID: On Thu, 18 Feb 2021 02:28:01 GMT, Jie Fu wrote: > Hi all, > > ASN1Formatter.annotate should be able to throw an IOException according to this comment [1]. > But it fails to do so due to the return [2] in the finally block, which would swallow the IOException. > > Generally, it seems not good to put a return statement in a finally block because it would overwrite other return-statements or Exceptions [3]. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L113 > [2] https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120 > [3] https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning This pull request has now been integrated. Changeset: b10376ba Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/b10376ba Stats: 15 lines in 1 file changed: 10 ins; 1 del; 4 mod 8261938: ASN1Formatter.annotate should not return in the finally block Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/2620 From isipka at openjdk.java.net Sat Feb 20 00:10:52 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Sat, 20 Feb 2021 00:10:52 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v6] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java ------------- Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=05 Stats: 435 lines in 6 files changed: 130 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From darcy at openjdk.java.net Sat Feb 20 00:12:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 20 Feb 2021 00:12:43 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 12:48:05 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove tabs from random/package-info.java src/java.base/share/classes/java/util/random/package-info.java line 193: > 191: * > 192: * > 193: *

      Random Number Generator Algorithms Available in Java SE

      Some comments and questions on the spec status of this table: is the intentional to require all of these algorithms in all compliant implementation of Java SE or just in the JDK reference implementation? Is the list intended to be exhaustive, meaning no other algorithms should be findable? I recommend clarifying the intended Java SE vs JDK status here. Also, I recommend including wording along the lines of "this list may change in the future" and "an implementation may provide additional algorithms" etc. Also, to aid future evolution of the set of algorithms, was there consideration of an "isDeprecated" predicate so that algorithms could be so-marked for a while before being dropped? ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From isipka at openjdk.java.net Sat Feb 20 00:17:10 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Sat, 20 Feb 2021 00:17:10 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v7] In-Reply-To: References: Message-ID: <5i6IXTCSx_-kiZM0bcTiHRonW_icbYR7zAncy5oWtUI=.4da01572-285f-465b-aaa1-7e084cd4805c@github.com> > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/d9d41ebd..23025452 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From dcubed at openjdk.java.net Sat Feb 20 02:19:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 20 Feb 2021 02:19:41 GMT Subject: RFR: 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> Message-ID: On Sat, 20 Feb 2021 00:44:29 GMT, Naoto Sato wrote: > The subject test case is failing under the JMS-enabled environment. Changes requested by dcubed (Reviewer). test/jdk/ProblemList.txt line 799: > 797: # jdk_util > 798: > 799: java/util/Locale/LocaleProvidersRun.java 8261919 generic-all This only needs to be ProblemListed on linux-x64. ------------- PR: https://git.openjdk.java.net/jdk/pull/2657 From naoto at openjdk.java.net Sat Feb 20 02:37:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 20 Feb 2021 02:37:41 GMT Subject: RFR: 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java In-Reply-To: References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> Message-ID: <2j_x1T04h9QPiS0G2N8bsZloaEW55b1fk-7KkUPEHcs=.0177ef38-5d74-4f58-9a4e-940c362f2553@github.com> On Sat, 20 Feb 2021 02:16:43 GMT, Daniel D. Daugherty wrote: >> The subject test case is failing under the JMS-enabled environment. > > test/jdk/ProblemList.txt line 799: > >> 797: # jdk_util >> 798: >> 799: java/util/Locale/LocaleProvidersRun.java 8261919 generic-all > > This only needs to be ProblemListed on linux-x64. It's not platform specific, but specific to the environment that is usage tracker enabled. Thus I put it as 'generic'. ------------- PR: https://git.openjdk.java.net/jdk/pull/2657 From joehw at openjdk.java.net Sat Feb 20 02:41:59 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 20 Feb 2021 02:41:59 GMT Subject: Integrated: 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 22:12:35 GMT, Joe Wang wrote: > A quick fix to the test, removing Windows carriage return in the result. This pull request has now been integrated. Changeset: 47559584 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/47559584 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858 Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/2656 From dl at openjdk.java.net Sat Feb 20 14:22:52 2021 From: dl at openjdk.java.net (Doug Lea) Date: Sat, 20 Feb 2021 14:22:52 GMT Subject: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) Message-ID: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 ------------- Commit messages: - JDK-8259800 Changes: https://git.openjdk.java.net/jdk/pull/2661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2661&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259800 Stats: 347 lines in 2 files changed: 175 ins; 106 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/2661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2661/head:pull/2661 PR: https://git.openjdk.java.net/jdk/pull/2661 From jlaskey at openjdk.java.net Sat Feb 20 15:20:42 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sat, 20 Feb 2021 15:20:42 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v21] In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 00:09:51 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tabs from random/package-info.java > > src/java.base/share/classes/java/util/random/package-info.java line 193: > >> 191: * >> 192: * >> 193: *

      Random Number Generator Algorithms Available in Java SE

      > > Some comments and questions on the spec status of this table: is the intentional to require all of these algorithms in all compliant implementation of Java SE or just in the JDK reference implementation? Is the list intended to be exhaustive, meaning no other algorithms should be findable? > > I recommend clarifying the intended Java SE vs JDK status here. Also, I recommend including wording along the lines of "this list may change in the future" and "an implementation may provide additional algorithms" etc. > > Also, to aid future evolution of the set of algorithms, was there consideration of an "isDeprecated" predicate so that algorithms could be so-marked for a while before being dropped? Precise advice on wording please. The table reflect algorithms guaranteed findable in JDK 17. Whether they are required in all other deployments is something the CSR review should define. "this list may change in the future" is a good idea. Not sure "isDeprecated" can be done in a meaningful way. This would require that users would have to add that filter to every query or have all() not include deprecated algorithms. Better to be prepared to handle not finding the algorithm. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From github.com+7806504+liach at openjdk.java.net Sat Feb 20 16:50:39 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sat, 20 Feb 2021 16:50:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v3] In-Reply-To: <84e4oda9As0m5jPdm1EcQOry30jgGHUaj0TUaYc26Fs=.7468ee66-2f76-43df-9b0f-16e9082b3b6d@github.com> References: <84e4oda9As0m5jPdm1EcQOry30jgGHUaj0TUaYc26Fs=.7468ee66-2f76-43df-9b0f-16e9082b3b6d@github.com> Message-ID: On Wed, 17 Feb 2021 19:56:01 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing ImmutableCollections.* idempotency In addition year for license of Collections.java needs an update too ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From darcy at openjdk.java.net Sat Feb 20 21:49:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 20 Feb 2021 21:49:53 GMT Subject: RFR: 8261290: Improve error message for NumberFormatException on null input Message-ID: In Integer and Long, several of the parsing methods are specified to throw NumberFormatException on a null input rather than an NPE. That behavior is not proposed to be modified. However, I think it is reasonable for the NumberFormatException to have a more informative error message than just "null" -- specifically "Cannot parse null string" is proposed here. All four prior occurrences of throw new NumberFormatException("null") have be updated; there were no other instances of this idiom in the java.lang package. All java/lang/{Integer, Long} regression tests pass with this change. ------------- Commit messages: - Initial commit. Changes: https://git.openjdk.java.net/jdk/pull/2663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261290 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2663/head:pull/2663 PR: https://git.openjdk.java.net/jdk/pull/2663 From attila at openjdk.java.net Sun Feb 21 12:49:44 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 21 Feb 2021 12:49:44 GMT Subject: RFR: 8261290: Improve error message for NumberFormatException on null input In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw NumberFormatException on a null input rather than an NPE. That behavior is not proposed to be modified. However, I think it is reasonable for the NumberFormatException to have a more informative error message than just "null" -- specifically "Cannot parse null string" is proposed here. > > All four prior occurrences of > > throw new NumberFormatException("null") > > have be updated; there were no other instances of this idiom in the java.lang package. > > All java/lang/{Integer, Long} regression tests pass with this change. Rather straightforward ?? ------------- Marked as reviewed by attila (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2663 From attila at openjdk.java.net Sun Feb 21 13:18:54 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 21 Feb 2021 13:18:54 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 11:22:57 GMT, Peter Levart wrote: >I would like 1st to understand why the MH created in the TestLinker.convertToType is actually GCed at all. The whole original issue was about allowing these objects to be GCd ??. Short story: because all data is scoped to objects created within `makeOne` method. Longer story: It is GC'd because its reachability is dominated by the `DynamicLinker` object created on [line 96](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java#L96). It and everything it dominates (`LinkerServicesImpl` object holding the `TypeConverterFactory` object holding the `BiClassValue` objects holding the method handles) become garbage as soon as the method exits. This works because of the pains I took in `BiClassValue` to ensure we don't leak any of the infrastructural objects through implicit `this$0` outer-class references into the `ClassValue`s. That allows the `ClassValue` objects to be GCd and removed from the classes' class-value mapping. This ordinarily doesn't happen as most `ClassValue` objects are bound to static fields, but in `TypeConverterFactory` the `BiClassValue` instances are specific to the `TypeConverterFactory` instance, so they are expected to be reclaimable by G C if the converter factory itself goes away. > And after that, why it is not GCed before 12 invocations to makeOne() are made. Because GC is at liberty to delay recognizing an object is phantom reachable? I don't think we need to read too much into this? Correct me if I don't see something. > What would be more interesting to test is to create a converter between a type loaded by a custom (child) ClassLoader and a system type. After that, release all hard references to the custom ClassLoader and see if the converter gets GC-ed as a result. WDYT? That does sound like [TypeConverterFactoryRetentionTests.testSystemLoaderToOtherLoader](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java#L118) True, it tests whether the _class loader_ itself gets released, not the converter, but the loader would hardly get released while there's a converter with the class from that loader bound in the parameter signature of its method handle, wouldn't it? Regardless, if you think there's a valid use case for this additional test, we can discuss it. I'd rather scope this issue to fixing the flakiness of the tests, so they don't cause trouble with builds and can be backported/added to ongoing backports. Thanks for taking time to look into this! ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From alanb at openjdk.java.net Sun Feb 21 15:51:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 21 Feb 2021 15:51:39 GMT Subject: RFR: 8261290: Improve error message for NumberFormatException on null input In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw NumberFormatException on a null input rather than an NPE. That behavior is not proposed to be modified. However, I think it is reasonable for the NumberFormatException to have a more informative error message than just "null" -- specifically "Cannot parse null string" is proposed here. > > All four prior occurrences of > > throw new NumberFormatException("null") > > have be updated; there were no other instances of this idiom in the java.lang package. > > All java/lang/{Integer, Long} regression tests pass with this change. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2663 From prr at openjdk.java.net Sun Feb 21 16:42:50 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 21 Feb 2021 16:42:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: > > - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos > - Re-do safefetch.hpp > - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos > - stubRoutines.inline.hpp -> safefetch.hpp > - Update copyrights > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Extract SafeFetch32/N to stubRoutines.inline.hpp > - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" > > This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. > - Merge pull request #9 from VladimirKempik/pull/2200 > > Removed unused variables > - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c Looks like the compiler warning changess are now the only desktop changes. That is fine by me. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200 From darcy at openjdk.java.net Sun Feb 21 18:46:40 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 21 Feb 2021 18:46:40 GMT Subject: Integrated: 8261290: Improve error message for NumberFormatException on null input In-Reply-To: References: Message-ID: On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw NumberFormatException on a null input rather than an NPE. That behavior is not proposed to be modified. However, I think it is reasonable for the NumberFormatException to have a more informative error message than just "null" -- specifically "Cannot parse null string" is proposed here. > > All four prior occurrences of > > throw new NumberFormatException("null") > > have be updated; there were no other instances of this idiom in the java.lang package. > > All java/lang/{Integer, Long} regression tests pass with this change. This pull request has now been integrated. Changeset: 564011cf Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/564011cf Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8261290: Improve error message for NumberFormatException on null input Reviewed-by: attila, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2663 From szegedia at gmail.com Sun Feb 21 20:14:48 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 21 Feb 2021 21:14:48 +0100 Subject: Class.getRecordComponents security checks Message-ID: <87EA37FD-B688-4EB3-B8E1-F51F6FB4273C@gmail.com> Hey folks, Why are security checks for Class.getRecordComponents as strict as those for e.g. getDeclaredMethods? I would?ve expected they?d be as strict as those for e.g. getMethods. Specifically, the difference is the: > ?the caller's class loader is not the same as the class loader of this class and invocation of s.checkPermission method with RuntimePermission("accessDeclaredMembers") denies access to the declared methods within this class? step. Aren?t record accessors supposed to be public? Attila. From forax at univ-mlv.fr Sun Feb 21 20:57:02 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 21 Feb 2021 21:57:02 +0100 (CET) Subject: Class.getRecordComponents security checks In-Reply-To: <87EA37FD-B688-4EB3-B8E1-F51F6FB4273C@gmail.com> References: <87EA37FD-B688-4EB3-B8E1-F51F6FB4273C@gmail.com> Message-ID: <838938525.1918410.1613941022924.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Attila Szegedi" > ?: "core-libs-dev" > Envoy?: Dimanche 21 F?vrier 2021 21:14:48 > Objet: Class.getRecordComponents security checks > Hey folks, > > Why are security checks for Class.getRecordComponents as strict as those for > e.g. getDeclaredMethods? I would?ve expected they?d be as strict as those for > e.g. getMethods. Specifically, the difference is the: > >> ?the caller's class loader is not the same as the class loader of this class and >> invocation of s.checkPermission method with >> RuntimePermission("accessDeclaredMembers") denies access to the declared >> methods within this class? Good question, getRecordComponents() list the record components not the record accessors, while each record component has a corresponding accessor method, the reverse is not true. so here, what you are asking is more like asking fields than methods, so it's more like getDeclaredFields() than getMethods(), hence the runtime check if there is a SecurityManager enabled. > > step. Aren?t record accessors supposed to be public? yes, at least for the code generated by javac, accessors are always public (the class itself may be non public, and the package may not be exported). > > Attila. R?mi From martin at openjdk.java.net Sun Feb 21 22:40:47 2021 From: martin at openjdk.java.net (Martin Buchholz) Date: Sun, 21 Feb 2021 22:40:47 GMT Subject: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) In-Reply-To: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> References: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> Message-ID: On Sat, 20 Feb 2021 14:17:16 GMT, Doug Lea
      wrote: > This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 Marked as reviewed by martin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2661 From dl at openjdk.java.net Sun Feb 21 23:22:00 2021 From: dl at openjdk.java.net (Doug Lea) Date: Sun, 21 Feb 2021 23:22:00 GMT Subject: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2] In-Reply-To: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> References: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> Message-ID: > This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 Doug Lea has updated the pull request incrementally with one additional commit since the last revision: JDK-8259800 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2661/files - new: https://git.openjdk.java.net/jdk/pull/2661/files/fa60b251..e0daa87a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2661&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2661&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2661/head:pull/2661 PR: https://git.openjdk.java.net/jdk/pull/2661 From dholmes at openjdk.java.net Mon Feb 22 02:53:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 22 Feb 2021 02:53:42 GMT Subject: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2] In-Reply-To: References: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> Message-ID: On Sun, 21 Feb 2021 23:22:00 GMT, Doug Lea
      wrote: >> This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8259800 Hi Doug, This looked a little more involved from the version I tested so I re-ran it through the tests - still passed okay :) Thanks for getting to the bottom of this one - remote debugging is not fun. Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2661 From david.holmes at oracle.com Mon Feb 22 04:17:52 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Feb 2021 14:17:52 +1000 Subject: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2] In-Reply-To: References: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com> <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com> Message-ID: On 20/02/2021 12:00 am, Naoto Sato wrote: > On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs wrote: > >>>> >>>> >>>> The table is informative and should not be construed as specification. >>>> The wording "has supported" should be sufficient. >>> >>> If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification? >> >> The current version of Unicode is specified in a normative statement just before the table. >> "Character information is based on the Unicode Standard, version 13.0." >> >> The table is not a specification of past revisions. > > RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released. Roger and Naoto, thanks for clarifying. I took Roger's original comment out of context. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2538 > From ewhelan at openjdk.java.net Mon Feb 22 09:50:06 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 22 Feb 2021 09:50:06 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v6] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: 8252883: Stripped back FileHandlerAccessTest to only use threads ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/b5259dcb..1bb8837e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=04-05 Stats: 58 lines in 1 file changed: 0 ins; 53 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Mon Feb 22 09:50:06 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Mon, 22 Feb 2021 09:50:06 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> References: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> Message-ID: On Fri, 19 Feb 2021 14:06:23 GMT, Daniel Fuchs wrote: >> LGTM > > I'm seeing some intermittent test failures with the new test (after merging in latest master changes). Can you retest and have a look: > > ----------System.out:(25/1343)---------- > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Testing with arguments: type=process, count=20 > Thread-2 |Error: Could not find or load main class FileHandlerAccessTest > Thread-2 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest > Thread-6 |Error: Could not find or load main class FileHandlerAccessTest > Thread-6 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest > Thread-1 |Error: Could not find or load main class FileHandlerAccessTest > Thread-1 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest > Testing with arguments: type=process, count=20 > ----------System.err:(14/1024)---------- > java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. > at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: An error occured in the child process. > at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) > ... 1 more > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. > java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. > at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: An error occured in the child process. > at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) > ... 1 more > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. > ----------rerun:(39/6191)*---------- Hi, I've removed the problematic "process" handling logic and have stripped the test back to only use threads. The problem was reproducible (intermittently on my Windows machine) using this smaller test and should make the test more stable. ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From jboes at openjdk.java.net Mon Feb 22 10:35:40 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 22 Feb 2021 10:35:40 GMT Subject: Integrated: 8248318: Remove superfluous use of boxing in ObjectStreamClass In-Reply-To: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> References: <35v6L4BL6izP4ip_Qni7w6y-UNFLIKQ9uNi_Randl_g=.4073d418-a57a-429d-af27-0ccf8318948a@github.com> Message-ID: On Fri, 19 Feb 2021 10:14:54 GMT, Julia Boes wrote: > This change removes some instances of superfluous boxing in java.io.ObjectStreamClass. > Testing: tier 1-3 all clear. This pull request has now been integrated. Changeset: e9d7c07b Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/e9d7c07b Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8248318: Remove superfluous use of boxing in ObjectStreamClass Reviewed-by: jlaskey, dfuchs, rriggs, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/2641 From eirbjo at gmail.com Mon Feb 22 11:26:13 2021 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 22 Feb 2021 12:26:13 +0100 Subject: ThreadLocal lookup elimination Message-ID: Hello, ThreadLocals are commonly used to transfer state across method boundaries in situations where passing them as method parameters is impractical. Examples include crossing APIs you don't own, or instrumenting code you don't own. Consider the following pseudo-instrumented code (where the original code calls a getter inside a loop): public class Student { private int age; public int maxAge(Student[] students) { // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); // Original code: int max = 0; for (Student student : students) { max = Math.max(max, student.getAge()); } return max; } public int getAge() { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code: return age; } // Instrumented field: private static ThreadLocal threadLocal = new ThreadLocal<>(); } The ThreadLocal is used here to avoid constructing ExpensiveObject instances in each invocation of getAge. However, once a compiler worth its salt sees this code, it immediately wants to inline the getAge method: // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); for (Student student : students) { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code max = Math.max(max, student.age); } At this point, we see that the last write to threadLocal is 'expensive', so any following 'threadLocal.get()' should be substitutable for 'expensive'. So we could do the following instead: for (Student student : students) { // Instrumented code expensive.recordSomething(); // Original code max = Math.max(max, student.age); } More generally, a compiler could record the first lookup of a ThreadLocal in a scope and substitute any following lookup with the first read (until the next write). I'm pretty sure this would be immensely useful for my current use case (which instruments methods to count invocations), but perhaps it is also a useful optimization in a more general sense? Examples that come to mind are enterprise apps where transaction and security contexts are passed around using ThreadLocals. Has this type of optimization been discussed before? Is it even possible to implement, or did I miss some dragons hiding in the details? What would the estimated work for an implementation look like? Are we looking at bachelor's thesis? Master's thesis? PhD? Would love to hear some thoughts on this idea. Cheers, Eirik. From dl at openjdk.java.net Mon Feb 22 12:45:38 2021 From: dl at openjdk.java.net (Doug Lea) Date: Mon, 22 Feb 2021 12:45:38 GMT Subject: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2] In-Reply-To: References: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> Message-ID: On Mon, 22 Feb 2021 02:50:34 GMT, David Holmes wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8259800 > > Hi Doug, > > This looked a little more involved from the version I tested so I re-ran it through the tests - still passed okay :) > > Thanks for getting to the bottom of this one - remote debugging is not fun. > > Cheers, > David Thanks David and Martin for the help. ------------- PR: https://git.openjdk.java.net/jdk/pull/2661 From dl at openjdk.java.net Mon Feb 22 12:45:39 2021 From: dl at openjdk.java.net (Doug Lea) Date: Mon, 22 Feb 2021 12:45:39 GMT Subject: Integrated: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) In-Reply-To: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> References: <8MjL6vOrtGfl_6V_9Fc-hYQ4bEyeJcPPrGn7qlBpUmI=.04579795-99cb-4cf6-9b0b-fb97a3753271@github.com> Message-ID: On Sat, 20 Feb 2021 14:17:16 GMT, Doug Lea
      wrote: > This addresses interactions between parallelism-0 and new shutdown support in https://bugs.openjdk.java.net/browse/JDK-8259800 This pull request has now been integrated. Changeset: 5b7b18c5 Author: Doug Lea
      URL: https://git.openjdk.java.net/jdk/commit/5b7b18c5 Stats: 347 lines in 2 files changed: 175 ins; 106 del; 66 mod 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) Reviewed-by: martin, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/2661 From jlaskey at openjdk.java.net Mon Feb 22 13:47:09 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 22 Feb 2021 13:47:09 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v22] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Revised javadoc per CSR reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/cfaf7cef..61f5d700 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=20-21 Stats: 31 lines in 3 files changed: 28 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From isipka at openjdk.java.net Mon Feb 22 15:24:19 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 22 Feb 2021 15:24:19 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v8] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/23025452..7133fe98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From iignatyev at openjdk.java.net Mon Feb 22 15:40:47 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 22 Feb 2021 15:40:47 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v8] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 15:24:19 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java Changes requested by iignatyev (Reviewer). test/jdk/java/lang/annotation/LoaderLeakTest.java line 80: > 78: System.gc(); > 79: System.gc(); > 80: if (c.get() == null) throw new AssertionError("class missing"); it would be better to use a different message here, so it would uniquely identify a failed check, e.g. `class missing after GC but before loader is unreachable` test/jdk/java/lang/annotation/LoaderLeakTest.java line 74: > 72: ClassLoader loader = new SimpleClassLoader(); > 73: var c = new WeakReference>(loader.loadClass("C")); > 74: if (c.get() == null) throw new AssertionError(); please add an exception message here as well. test/jdk/java/lang/annotation/LoaderLeakTest.java line 68: > 66: public static void main(String[] args) throws Exception { > 67: for (int i=0; i<100; i++) > 68: doTest(args.length != 0); nit: it's usually better to use `{`/`}` even for a one-line loop block. test/jdk/java/lang/annotation/LoaderLeakTest.java line 99: > 97: } > 98: > 99: @java.lang.annotation.Retention(RUNTIME) nit: `import java.lang.annotation.Retention;` test/jdk/java/lang/annotation/LoaderLeakTest.java line 59: > 57: private void runJavaProcessExpectSuccessExitCode(String ... command) throws Throwable { > 58: var processBuilder = ProcessTools.createJavaProcessBuilder(command) > 59: .directory(Paths.get(Utils.TEST_CLASSES).toFile()); nit: in the case of chain calls, lines should be aligned by `.` test/jdk/java/lang/annotation/LoaderLeakTest.java line 28: > 26: * @bug 5040740 > 27: * @summary annotations cause memory leak > 28: * @author gafter not sure about etiquette in core-libs testsuite, but in hotspot testsuite, we tend not to use `@author` tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From iignatyev at openjdk.java.net Mon Feb 22 15:40:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 22 Feb 2021 15:40:48 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v8] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 15:33:30 GMT, Igor Ignatyev wrote: >> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: >> >> 8166026: Refactor java/lang shell tests to java > > test/jdk/java/lang/annotation/LoaderLeakTest.java line 68: > >> 66: public static void main(String[] args) throws Exception { >> 67: for (int i=0; i<100; i++) >> 68: doTest(args.length != 0); > > nit: it's usually better to use `{`/`}` even for a one-line loop block. nit 2: `=` and `<` should be surrounded by a space. ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From isipka at openjdk.java.net Mon Feb 22 15:50:03 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 22 Feb 2021 15:50:03 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v9] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/7133fe98..9e99a760 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=07-08 Stats: 12 lines in 1 file changed: 5 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From naoto at openjdk.java.net Mon Feb 22 17:03:05 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 22 Feb 2021 17:03:05 GMT Subject: RFR: 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java [v2] In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> Message-ID: > The subject test case is failing under the JMS-enabled environment. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Limit the exclustion to linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2657/files - new: https://git.openjdk.java.net/jdk/pull/2657/files/7c9cf40e..6a6bc241 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2657&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2657&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2657/head:pull/2657 PR: https://git.openjdk.java.net/jdk/pull/2657 From dfuchs at openjdk.java.net Mon Feb 22 17:03:48 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 22 Feb 2021 17:03:48 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v9] In-Reply-To: References: Message-ID: <8gG_RsI5QRXeuPL9AlfOMmiNuWOkSWlOX4QQIuWFans=.6457f984-327b-49e3-aa0b-6ce08bc806fc@github.com> On Mon, 22 Feb 2021 15:50:03 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java test/jdk/java/lang/annotation/LoaderLeakTest.java line 77: > 75: var c = new WeakReference>(loader.loadClass("C")); > 76: if (c.get() == null) throw new AssertionError("class missing after loadClass"); > 77: if (c.get().getClassLoader() != loader) throw new AssertionError("wrong classloader"); This can throw NPE as there is no guarantee that two subsequent calls will return the same value: c.get() could very well be null the second time around. test/jdk/java/lang/annotation/LoaderLeakTest.java line 94: > 92: System.gc(); > 93: Thread.sleep(20); > 94: if (c.get() == null) { I'd suggest using the new `if (c.refersTo(null)) {` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1577 From isipka at openjdk.java.net Mon Feb 22 17:27:06 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 22 Feb 2021 17:27:06 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v10] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/9e99a760..c9a69083 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From isipka at openjdk.java.net Mon Feb 22 20:35:19 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Mon, 22 Feb 2021 20:35:19 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v11] In-Reply-To: References: Message-ID: > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: 8166026: Refactor java/lang shell tests to java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1577/files - new: https://git.openjdk.java.net/jdk/pull/1577/files/c9a69083..bf49de6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=09-10 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From psandoz at openjdk.java.net Mon Feb 22 22:01:46 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 22 Feb 2021 22:01:46 GMT Subject: RFR: 8261975: Missing "classpath exception" in VectorSupport.java Message-ID: <5uX6CAC0E-SujReiQYOuLbj5CKRFn1btrA4N6fdqDT8=.dd9413c3-4aae-41d8-906e-193f0eb26096@github.com> Add missing classpath exception paragraph ------------- Commit messages: - 8261975: Missing "classpath exception" in VectorSupport.java Changes: https://git.openjdk.java.net/jdk/pull/2678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261975 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2678/head:pull/2678 PR: https://git.openjdk.java.net/jdk/pull/2678 From igraves at openjdk.java.net Mon Feb 22 22:08:56 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 22 Feb 2021 22:08:56 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: Message-ID: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Updating Collections.java copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2596/files - new: https://git.openjdk.java.net/jdk/pull/2596/files/a9588e9c..ebdd0f85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596 From mchung at openjdk.java.net Mon Feb 22 23:17:40 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 22 Feb 2021 23:17:40 GMT Subject: RFR: 8261975: Missing "classpath exception" in VectorSupport.java In-Reply-To: <5uX6CAC0E-SujReiQYOuLbj5CKRFn1btrA4N6fdqDT8=.dd9413c3-4aae-41d8-906e-193f0eb26096@github.com> References: <5uX6CAC0E-SujReiQYOuLbj5CKRFn1btrA4N6fdqDT8=.dd9413c3-4aae-41d8-906e-193f0eb26096@github.com> Message-ID: <2acK2a1oYdN-w3r7FakWhWfoMdRW-sWPUEnEV9bIU6k=.27bae1ee-8a59-4b9d-b492-d4eaeeff17af@github.com> On Mon, 22 Feb 2021 21:57:00 GMT, Paul Sandoz wrote: > Add missing classpath exception paragraph Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2678 From bpb at openjdk.java.net Mon Feb 22 23:36:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 22 Feb 2021 23:36:53 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides Message-ID: 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides ------------- Commit messages: - 8258444: Fix trailing whitesoace - 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides Changes: https://git.openjdk.java.net/jdk/pull/2680/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258444 Stats: 156 lines in 9 files changed: 41 ins; 57 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2680/head:pull/2680 PR: https://git.openjdk.java.net/jdk/pull/2680 From bpb at openjdk.java.net Mon Feb 22 23:36:53 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 22 Feb 2021 23:36:53 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: <1g6MmwX5pDDr5Vyh3ceiav2155DCu2cObCynb4MZ6os=.7b61a922-387e-4603-982a-3f7fadaee9bf@github.com> On Mon, 22 Feb 2021 23:27:19 GMT, Brian Burkhalter wrote: > 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides This change proposes to use {@inheritDoc} to improve consistency of the specification of `Reader.read(char[],in,in)` in `Reader` and its subclasses. In the course of this, some bounds checks are replaced with `Objects.checkFromIndexSize()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From redestad at openjdk.java.net Mon Feb 22 23:41:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 22 Feb 2021 23:41:40 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 22:08:56 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Updating Collections.java copyright This looks good to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2596 From psandoz at openjdk.java.net Tue Feb 23 00:48:39 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 23 Feb 2021 00:48:39 GMT Subject: Integrated: 8261975: Missing "classpath exception" in VectorSupport.java In-Reply-To: <5uX6CAC0E-SujReiQYOuLbj5CKRFn1btrA4N6fdqDT8=.dd9413c3-4aae-41d8-906e-193f0eb26096@github.com> References: <5uX6CAC0E-SujReiQYOuLbj5CKRFn1btrA4N6fdqDT8=.dd9413c3-4aae-41d8-906e-193f0eb26096@github.com> Message-ID: <3k_EQ9hjf3SZZkHm9qhyIxSNDxNeXXyXk_ozRDGWx30=.7c7d619c-ae21-4201-ac15-441468cc84e5@github.com> On Mon, 22 Feb 2021 21:57:00 GMT, Paul Sandoz wrote: > Add missing classpath exception paragraph This pull request has now been integrated. Changeset: 0217d699 Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/0217d699 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8261975: Missing "classpath exception" in VectorSupport.java Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/2678 From naoto at openjdk.java.net Tue Feb 23 02:13:46 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 23 Feb 2021 02:13:46 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" Message-ID: Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. ------------- Commit messages: - 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" Changes: https://git.openjdk.java.net/jdk/pull/2683/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261919 Stats: 31 lines in 2 files changed: 17 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2683/head:pull/2683 PR: https://git.openjdk.java.net/jdk/pull/2683 From darcy at openjdk.java.net Tue Feb 23 04:04:53 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 23 Feb 2021 04:04:53 GMT Subject: RFR: 8253409: Double-rounding possibility in float fma Message-ID: In floating-point, usually doing an operation to double precision and then rounding to float gives the right result in float precision. One exception to this is fused multiply add (fma) where "a * b + c" is computed with a single rounding. This requires the equivalent of extra intermediate precision inside the operation. If a float fma is implemented using a double fma rounded to float, for some well-chosen arguments where the final result is near a half-way result in *float*, an incorrect answer will be computed due to double rounding. In more detail, the double result will round up and then the cast to float will round up again whereas a single rounding of the exact answer to float would only round-up once. The new float fma implementation does the exact arithmetic using BigDecimal where possible, with guard to handle the non-finite and signed zero IEEE 754 details. ------------- Commit messages: - 8253409: Double-rounding possibility in float fma Changes: https://git.openjdk.java.net/jdk/pull/2684/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2684&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253409 Stats: 31 lines in 2 files changed: 3 ins; 11 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/2684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2684/head:pull/2684 PR: https://git.openjdk.java.net/jdk/pull/2684 From darcy at openjdk.java.net Tue Feb 23 06:15:39 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 23 Feb 2021 06:15:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 23:39:15 GMT, Claes Redestad wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating Collections.java copyright > > This looks good to me. Is there any behavior change here that merits a CSR review? ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From darcy at openjdk.java.net Tue Feb 23 07:00:07 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 23 Feb 2021 07:00:07 GMT Subject: RFR: 8253409: Double-rounding possibility in float fma [v2] In-Reply-To: References: Message-ID: > In floating-point, usually doing an operation to double precision and then rounding to float gives the right result in float precision. One exception to this is fused multiply add (fma) where "a * b + c" is computed with a single rounding. This requires the equivalent of extra intermediate precision inside the operation. If a float fma is implemented using a double fma rounded to float, for some well-chosen arguments where the final result is near a half-way result in *float*, an incorrect answer will be computed due to double rounding. In more detail, the double result will round up and then the cast to float will round up again whereas a single rounding of the exact answer to float would only round-up once. > > The new float fma implementation does the exact arithmetic using BigDecimal where possible, with guard to handle the non-finite and signed zero IEEE 754 details. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add a jtreg run command to disable any fma instrinic so the Java code is tested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2684/files - new: https://git.openjdk.java.net/jdk/pull/2684/files/9d26b312..ee2ea23a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2684&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2684&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2684/head:pull/2684 PR: https://git.openjdk.java.net/jdk/pull/2684 From joehw at openjdk.java.net Tue Feb 23 07:31:38 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 23 Feb 2021 07:31:38 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato wrote: > Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2683 From alanb at openjdk.java.net Tue Feb 23 08:51:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 23 Feb 2021 08:51:41 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 23:27:19 GMT, Brian Burkhalter wrote: > 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/io/InputStreamReader.java line 167: > 165: * {@inheritDoc} > 166: */ > 167: public int read(char[] cbuf, int off, int len) throws IOException { IOOBE is unchecked, are you sure it gets inherited into the sub-class here? ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From dfuchs at openjdk.java.net Tue Feb 23 09:53:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 09:53:40 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato wrote: > Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. test/jdk/java/util/Locale/LocaleProviders.java line 416: > 414: // Set the root logger on loading the logging class > 415: public static class LogConfig { > 416: final static LogRecord[] lra = new LogRecord[1]; I would suggest to use some multi-thread safe container rather than a simple array to store the LogRecord. For instance - a CopyOnWriteArrayList - or something like that. Also you may want to harden the test by allowing for the possibility that some other logging might have occurred, and search the list for the record you expect rather than assuming it will be the first and only one. Otherwise looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/2683 From dfuchs at openjdk.java.net Tue Feb 23 10:19:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 10:19:40 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> Message-ID: On Mon, 22 Feb 2021 09:46:56 GMT, Evan Whelan wrote: >> I'm seeing some intermittent test failures with the new test (after merging in latest master changes). Can you retest and have a look: >> >> ----------System.out:(25/1343)---------- >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Testing with arguments: type=process, count=20 >> Thread-2 |Error: Could not find or load main class FileHandlerAccessTest >> Thread-2 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest >> Thread-6 |Error: Could not find or load main class FileHandlerAccessTest >> Thread-6 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest >> Thread-1 |Error: Could not find or load main class FileHandlerAccessTest >> Thread-1 |Caused by: java.lang.ClassNotFoundException: FileHandlerAccessTest >> Testing with arguments: type=process, count=20 >> ----------System.err:(14/1024)---------- >> java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. >> at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.RuntimeException: An error occured in the child process. >> at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) >> ... 1 more >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. >> java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. >> at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:96) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.RuntimeException: An error occured in the child process. >> at FileHandlerAccessTest.accessProcess(FileHandlerAccessTest.java:93) >> ... 1 more >> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: java.lang.RuntimeException: An error occured in the child process. >> ----------rerun:(39/6191)*---------- > > Hi, > > I've removed the problematic "process" handling logic and have stripped the test back to only use threads. > > The problem was reproducible (intermittently on my Windows machine) using this smaller test and should make the test more stable. Does the new version of the test still occasionally catches the issue and fails if the fix is not present? ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Tue Feb 23 10:19:43 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 10:19:43 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v6] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 09:50:06 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > 8252883: Stripped back FileHandlerAccessTest to only use threads test/jdk/java/util/logging/FileHandlerAccessTest.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. This seems like a new test - should it only have: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Tue Feb 23 11:10:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 11:10:40 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v11] In-Reply-To: References: Message-ID: <0B5RkvphlpP46TGQzHj4S3NZPKQ7eAauWBVps_gPas4=.7093dc75-3563-40b8-922b-fe0425d765ec@github.com> On Mon, 22 Feb 2021 20:35:19 GMT, Ivan ?ipka wrote: >> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > 8166026: Refactor java/lang shell tests to java changes look good to me - though not strictly necessary, I wonder if you should null out the local variables that hold the class and classloader just after the reachability fence. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1577 From ewhelan at openjdk.java.net Tue Feb 23 12:05:42 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 23 Feb 2021 12:05:42 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v6] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 10:14:07 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252883: Stripped back FileHandlerAccessTest to only use threads > > test/jdk/java/util/logging/FileHandlerAccessTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. > > This seems like a new test - should it only have: > > * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > ``` Thanks, will update ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Tue Feb 23 12:15:08 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 23 Feb 2021 12:15:08 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v7] In-Reply-To: References: Message-ID: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright year in FileHandlerAccessTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2572/files - new: https://git.openjdk.java.net/jdk/pull/2572/files/1bb8837e..c3b1d81d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2572&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2572/head:pull/2572 PR: https://git.openjdk.java.net/jdk/pull/2572 From ewhelan at openjdk.java.net Tue Feb 23 12:15:08 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 23 Feb 2021 12:15:08 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> Message-ID: On Tue, 23 Feb 2021 10:16:26 GMT, Daniel Fuchs wrote: >> Hi, >> >> I've removed the problematic "process" handling logic and have stripped the test back to only use threads. >> >> The problem was reproducible (intermittently on my Windows machine) using this smaller test and should make the test more stable. > > Does the new version of the test still occasionally catches the issue and fails if the fix is not present? Hi, locally this test reproduces the issue on my Windows machine. I believe our internal testing Windows boxes are too powerful and handle the threading too efficiently to reproduce this error. I can reproduce locally approx 10% of the time, but after over 100 runs I cannot reproduce as part of our internal testing. As this is not verifiable in a completely deterministic way, I believe having the test as a stable, passing test is a more appropriate approach instead of selecting this as no-reg hard. It adds more test coverage to the code also. ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Tue Feb 23 13:11:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 13:11:44 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v7] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 12:15:08 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright year in FileHandlerAccessTest.java Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From dfuchs at openjdk.java.net Tue Feb 23 13:11:45 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 13:11:45 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v5] In-Reply-To: References: <64eB3VF3EMnN4V98pr7Smgwj0jc5fR2QxRljJxwUR5Y=.eb788d1b-1ad0-48e2-9db3-5e75c20376d3@github.com> Message-ID: On Tue, 23 Feb 2021 12:10:30 GMT, Evan Whelan wrote: >> Does the new version of the test still occasionally catches the issue and fails if the fix is not present? > > Hi, locally this test reproduces the issue on my Windows machine. > > I believe our internal testing Windows boxes are too powerful and handle the threading too efficiently to reproduce this error. > > I can reproduce locally approx 10% of the time, but after over 100 runs I cannot reproduce as part of our internal testing. > > As this is not verifiable in a completely deterministic way, I believe having the test as a stable, passing test is a more appropriate approach instead of selecting this as no-reg hard. > > It adds more test coverage to the code also. Reproducing locally with the test is fine. That's enough for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From turbanoff at gmail.com Tue Feb 23 13:37:49 2021 From: turbanoff at gmail.com (Andrey Turbanov) Date: Tue, 23 Feb 2021 16:37:49 +0300 Subject: Fast and cheap (Double|Float)::toString Java algorithm Message-ID: >The last implementation is available in pre-Skara webrev form, as referenced in [2] Hope to see it as a github review soon! Andrey Turbanov From ewhelan at openjdk.java.net Tue Feb 23 14:02:42 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 23 Feb 2021 14:02:42 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v7] In-Reply-To: References: Message-ID: <6boTVoGhnPXN6BtuKMXnfcCfnOUFAgqXREFXeg38-Lc=.c90cb74b-21d8-4830-93fe-01e76a749eac@github.com> On Tue, 23 Feb 2021 13:08:29 GMT, Daniel Fuchs wrote: >> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed copyright year in FileHandlerAccessTest.java > > Marked as reviewed by dfuchs (Reviewer). Thanks for the feedback Daniel! As I've already posted the integrate command, I believe all this needs now is a sponsor :) ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From mbaesken at openjdk.java.net Tue Feb 23 14:03:52 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 23 Feb 2021 14:03:52 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c Message-ID: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Sonar reports a finding in args.c, where a file check is done . Stat performs a check on file, and later fopen is called on the file : https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CL0BBG2CXpcnhtM&resolved=false&types=VULNERABILITY The coding could be slightly rewritten so that the potential TOCTOU is removed (however I do not think that it is such a big issue). ------------- Commit messages: - JDK-8262199 Changes: https://git.openjdk.java.net/jdk/pull/2692/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262199 Stats: 32 lines in 1 file changed: 12 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692 PR: https://git.openjdk.java.net/jdk/pull/2692 From jlaskey at openjdk.java.net Tue Feb 23 14:07:02 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 14:07:02 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v23] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Various corrects ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/61f5d700..eeab6454 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=21-22 Stats: 34 lines in 4 files changed: 20 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From clanger at openjdk.java.net Tue Feb 23 14:08:43 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 23 Feb 2021 14:08:43 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CL0BBG2CXpcnhtM&resolved=false&types=VULNERABILITY > > The coding could be slightly rewritten so that the potential TOCTOU is removed (however I do not think that it is such a big issue). This looks good in general. Do you know whether there's a jtreg test that stresses arg files? src/java.base/share/native/libjli/args.c line 361: > 359: if (fptr != NULL) fclose(fptr); > 360: exit(1); > 361: } Can you insert a blank line here? ------------- Changes requested by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2692 From jlaskey at openjdk.java.net Tue Feb 23 14:14:04 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 14:14:04 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v24] In-Reply-To: References: Message-ID: <8yP2fkwGtSY6TDhYSRw9kCjAPru-mVik-6R_oJsK9Nc=.c89ee245-7a76-4933-b785-81ed117a887a@github.com> > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: L32X64StarStarRandom -> L32X64MixRandom ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/eeab6454..58a05f4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=22-23 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From mbaesken at openjdk.java.net Tue Feb 23 14:26:44 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 23 Feb 2021 14:26:44 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Tue, 23 Feb 2021 14:05:15 GMT, Christoph Langer wrote: > This looks good in general. Do you know whether there's a jtreg test that stresses arg files? There are tests dealing with args files at test/jdk/tools/launcher/ , e.g. there is test/jdk/tools/launcher/ArgsFileTest.java . Best regards, Matthias ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From mbaesken at openjdk.java.net Tue Feb 23 14:33:08 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 23 Feb 2021 14:33:08 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c [v2] In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: <26G44gqhn7uoUoofPtyliwmNPP27MErSVV-K4sOzrKY=.65cd1098-e081-4fba-9b74-ed2ac3221889@github.com> > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CL0BBG2CXpcnhtM&resolved=false&types=VULNERABILITY > > The coding could be slightly rewritten so that the potential TOCTOU is removed (however I do not think that it is such a big issue). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Small changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2692/files - new: https://git.openjdk.java.net/jdk/pull/2692/files/78467273..8b106a14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692 PR: https://git.openjdk.java.net/jdk/pull/2692 From clanger at openjdk.java.net Tue Feb 23 14:33:09 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 23 Feb 2021 14:33:09 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c [v2] In-Reply-To: <26G44gqhn7uoUoofPtyliwmNPP27MErSVV-K4sOzrKY=.65cd1098-e081-4fba-9b74-ed2ac3221889@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> <26G44gqhn7uoUoofPtyliwmNPP27MErSVV-K4sOzrKY=.65cd1098-e081-4fba-9b74-ed2ac3221889@github.com> Message-ID: On Tue, 23 Feb 2021 14:30:17 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file : >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CL0BBG2CXpcnhtM&resolved=false&types=VULNERABILITY >> >> The coding could be slightly rewritten so that the potential TOCTOU is removed (however I do not think that it is such a big issue). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Small changes Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From clanger at openjdk.java.net Tue Feb 23 14:33:09 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 23 Feb 2021 14:33:09 GMT Subject: RFR: JDK-8262199: TOCTOU in jli args.c [v2] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: <8BQS36zaHSo8LdlMG4-cljuy4KsgTlWSU-9_oKEpGMo=.6540b5dd-77e3-41c2-a45d-9144e42c2b8b@github.com> On Tue, 23 Feb 2021 14:23:59 GMT, Matthias Baesken wrote: > > This looks good in general. Do you know whether there's a jtreg test that stresses arg files? > > There are tests dealing with args files at test/jdk/tools/launcher/ , e.g. there is test/jdk/tools/launcher/ArgsFileTest.java . > > Best regards, Matthias OK, I added label noreg-sqe to the bug then. ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From info at j-kuhn.de Tue Feb 23 14:38:49 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 23 Feb 2021 15:38:49 +0100 Subject: JDK-8262003: Class.arrayType should not throw IllegalArgumentException Message-ID: I want to learn about writing a CSR, and need a sponsor teaching me the ropes. ---- Bug: https://bugs.openjdk.java.net/browse/JDK-8262003 Currently, Class.arrayType() will throw an IllegalArgumentException if the maximum number of dimensions will be exceeded. Throwing an IllegalArgumentException from a method that doesn't take an argument is, at least, strange. Therefore I would like to update the specification to allow this method to throw an IllegalStateException, similar to what ClassDesc.arrayType() does. ---- The current plan is: * Create a CSR detailing the spec changes: https://bugs.openjdk.java.net/browse/JDK-8262211 * Surround the code with a try-catch block. Checking for the error case is hard, and somewhat rare, so I think this is appropriate. * Copy the @throws javadoc line from ClassDesc.arrayType to Class.arrayType But there are a few questions I would love to get the answer on: * Both Class.arrayType() and ClassDesc.arrayType() are specified by TypeDescriptor.OfField. Should the specification of TypeDescriptor.OfField.arrayType() changed as well? * Is the draft of my CSR fine? Should I add some details, or omit things? Rephrase things? In advance, thanks for any support and feedback on this. - Johannes From redestad at openjdk.java.net Tue Feb 23 16:21:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 23 Feb 2021 16:21:41 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 06:12:54 GMT, Joe Darcy wrote: > Is there any behavior change here that merits a CSR review? Maybe. The one observable change is that calling `Collections.bar(foo)` with a `foo` that is already a `bar` will return the instance rather than unnecessarily wrap it. This could change semantics in applications inadvertently or deliberately relying on identity. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From bpb at openjdk.java.net Tue Feb 23 16:22:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 16:22:40 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 08:48:16 GMT, Alan Bateman wrote: >> 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides > > src/java.base/share/classes/java/io/InputStreamReader.java line 167: > >> 165: * {@inheritDoc} >> 166: */ >> 167: public int read(char[] cbuf, int off, int len) throws IOException { > > IOOBE is unchecked, are you sure it gets inherited into the sub-class here? It does not due to https://bugs.openjdk.java.net/browse/JDK-8157677. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From alanb at openjdk.java.net Tue Feb 23 16:25:45 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 23 Feb 2021 16:25:45 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 16:19:41 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/InputStreamReader.java line 167: >> >>> 165: * {@inheritDoc} >>> 166: */ >>> 167: public int read(char[] cbuf, int off, int len) throws IOException { >> >> IOOBE is unchecked, are you sure it gets inherited into the sub-class here? > > It does not due to https://bugs.openjdk.java.net/browse/JDK-8157677. The long standard behavior is that javadoc doesn't copy the throws of unchecked exceptions, instead we've had to declare the throws and use inheritDoc. I assume you'll need to do that here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From igraves at openjdk.java.net Tue Feb 23 16:29:59 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 23 Feb 2021 16:29:59 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: Message-ID: <0Q1-b9nmt14hoihSeDUReR8QUMvB8_6VOxg1edY6p_Y=.f3ee334f-fa4a-4eb9-b7b2-acf88022567f@github.com> On Tue, 23 Feb 2021 16:18:29 GMT, Claes Redestad wrote: > > Is there any behavior change here that merits a CSR review? > > Maybe. The one observable change is that calling `Collections.bar(foo)` with a `foo` that is already a `bar` will return the instance rather than unnecessarily wrap it. This could change semantics in applications inadvertently or deliberately relying on identity. Yes. The CSR was to consider primarily this case. Probably out of an abundance of caution here. @stuart-marks may have another case to consider. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From jlaskey at openjdk.java.net Tue Feb 23 16:47:59 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 23 Feb 2021 16:47:59 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25] In-Reply-To: References: Message-ID: > This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey 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 8248862 - Adjust ThreadLocalRandom javadoc inheritence - L32X64StarStarRandom -> L32X64MixRandom - Various corrects - Revised javadoc per CSR reviews - Remove tabs from random/package-info.java - Correct copyright notice. - Merge branch 'master' into 8248862 - Update tests for RandomGeneratorFactory.all() - Merge branch 'master' into 8248862 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=24 Stats: 13693 lines in 26 files changed: 11542 ins; 2066 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292 From bpb at openjdk.java.net Tue Feb 23 17:07:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 17:07:38 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: <3WCTIMg10C1NO-bV5pYDnZBM_FpkZznmQ9AGSo8_8uk=.8def5658-d95b-4e7d-9352-69e3769dd630@github.com> On Tue, 23 Feb 2021 16:23:10 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/InputStreamReader.java line 167: >> >>> 165: * {@inheritDoc} >>> 166: */ >>> 167: public int read(char[] cbuf, int off, int len) throws IOException { >> >> IOOBE is unchecked, are you sure it gets inherited into the sub-class here? > > The long standard behavior is that javadoc doesn't copy the throws of unchecked exceptions, instead we've had to declare the throws and use inheritDoc. I assume you'll need to do that here. It does not and there is a javadoc issue already on file about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From ewhelan at openjdk.java.net Tue Feb 23 17:35:44 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Tue, 23 Feb 2021 17:35:44 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v7] In-Reply-To: <6boTVoGhnPXN6BtuKMXnfcCfnOUFAgqXREFXeg38-Lc=.c90cb74b-21d8-4830-93fe-01e76a749eac@github.com> References: <6boTVoGhnPXN6BtuKMXnfcCfnOUFAgqXREFXeg38-Lc=.c90cb74b-21d8-4830-93fe-01e76a749eac@github.com> Message-ID: On Tue, 23 Feb 2021 14:00:16 GMT, Evan Whelan wrote: >> Marked as reviewed by dfuchs (Reviewer). > > Thanks for the feedback Daniel! As I've already posted the integrate command, I believe all this needs now is a sponsor :) Oops, never mind I've to re-issue the command ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From bpb at openjdk.java.net Tue Feb 23 17:42:58 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 17:42:58 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: > 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2680/files - new: https://git.openjdk.java.net/jdk/pull/2680/files/c96c80f0..687ad124 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2680&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2680&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2680/head:pull/2680 PR: https://git.openjdk.java.net/jdk/pull/2680 From github.com+4410404+vyommani at openjdk.java.net Tue Feb 23 17:44:44 2021 From: github.com+4410404+vyommani at openjdk.java.net (Vyom Mani Tewari) Date: Tue, 23 Feb 2021 17:44:44 GMT Subject: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v7] In-Reply-To: References: Message-ID: <3VCoCB0i-XWB8NiEuUBO_7-261Z_NZOA2RHu2tQnVlA=.befeae25-5bdd-41c5-b180-d43300a863e9@github.com> On Tue, 23 Feb 2021 12:15:08 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. >> >> This fix passes all testing. >> >> Kind regards, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright year in FileHandlerAccessTest.java Looks OK to me, although at my local Windows 10 box test took more than 100 iteration before it failed. ------------- Marked as reviewed by vyommani at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/2572 From alanb at openjdk.java.net Tue Feb 23 18:03:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 23 Feb 2021 18:03:39 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:42:58 GMT, Brian Burkhalter wrote: >> 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From naoto at openjdk.java.net Tue Feb 23 18:42:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 23 Feb 2021 18:42:41 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 09:49:47 GMT, Daniel Fuchs wrote: >> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. > > test/jdk/java/util/Locale/LocaleProviders.java line 416: > >> 414: // Set the root logger on loading the logging class >> 415: public static class LogConfig { >> 416: final static LogRecord[] lra = new LogRecord[1]; > > I would suggest to use some multi-thread safe container rather than a simple array to store the LogRecord. For instance - a CopyOnWriteArrayList - or something like that. Also you may want to harden the test by allowing for the possibility that some other logging might have occurred, and search the list for the record you expect rather than assuming it will be the first and only one. > Otherwise looks good! Thanks, Daniel. Will update the fix as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/2683 From bpb at openjdk.java.net Tue Feb 23 19:13:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 19:13:40 GMT Subject: RFR: 8253409: Double-rounding possibility in float fma [v2] In-Reply-To: References: Message-ID: <-XTBCNed01mff7sb7vGEz_FfZaIke1BC3oJDGGVnNBg=.0f1ce5d2-3dca-48ec-9873-e17add256f0d@github.com> On Tue, 23 Feb 2021 07:00:07 GMT, Joe Darcy wrote: >> In floating-point, usually doing an operation to double precision and then rounding to float gives the right result in float precision. One exception to this is fused multiply add (fma) where "a * b + c" is computed with a single rounding. This requires the equivalent of extra intermediate precision inside the operation. If a float fma is implemented using a double fma rounded to float, for some well-chosen arguments where the final result is near a half-way result in *float*, an incorrect answer will be computed due to double rounding. In more detail, the double result will round up and then the cast to float will round up again whereas a single rounding of the exact answer to float would only round-up once. >> >> The new float fma implementation does the exact arithmetic using BigDecimal where possible, with guard to handle the non-finite and signed zero IEEE 754 details. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add a jtreg run command to disable any fma instrinic so the Java code is tested. Looks fine. Presumably the updated test fails without the source change. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2684 From alanb at openjdk.java.net Tue Feb 23 19:27:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 23 Feb 2021 19:27:41 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v2] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Tue, 23 Feb 2021 14:04:29 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Small changes > > src/java.base/share/native/libjli/args.c line 361: > >> 359: if (fptr != NULL) fclose(fptr); >> 360: exit(1); >> 361: } > > Can you insert a blank line here? This function is "optionally report, optionally fclose, and then exit". Have you tried reducing it to reportAndExit and fclose inline in expandArgFile to avoid it doing 3 things? ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From naoto at openjdk.java.net Tue Feb 23 19:35:55 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 23 Feb 2021 19:35:55 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" [v2] In-Reply-To: References: Message-ID: <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com> > Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2683/files - new: https://git.openjdk.java.net/jdk/pull/2683/files/bfa3a8e5..4d82e8aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2683&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2683&range=00-01 Stats: 9 lines in 1 file changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2683/head:pull/2683 PR: https://git.openjdk.java.net/jdk/pull/2683 From darcy at openjdk.java.net Tue Feb 23 19:39:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 23 Feb 2021 19:39:41 GMT Subject: RFR: 8253409: Double-rounding possibility in float fma [v2] In-Reply-To: <-XTBCNed01mff7sb7vGEz_FfZaIke1BC3oJDGGVnNBg=.0f1ce5d2-3dca-48ec-9873-e17add256f0d@github.com> References: <-XTBCNed01mff7sb7vGEz_FfZaIke1BC3oJDGGVnNBg=.0f1ce5d2-3dca-48ec-9873-e17add256f0d@github.com> Message-ID: On Tue, 23 Feb 2021 19:11:06 GMT, Brian Burkhalter wrote: > > > Looks fine. Presumably the updated test fails without the source change. Right; the added test case is the failing one from the bug report. It will fail if the old non-intrinsic implementation, that is the Java implementation is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/2684 From darcy at openjdk.java.net Tue Feb 23 19:44:40 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 23 Feb 2021 19:44:40 GMT Subject: Integrated: 8253409: Double-rounding possibility in float fma In-Reply-To: References: Message-ID: <3bCwcScmiRrNFn_D1h3-dcZ8Qa6OrrUFbLx9RwRWmLY=.963c7510-e6c9-4cce-b535-e920a4801790@github.com> On Tue, 23 Feb 2021 03:58:46 GMT, Joe Darcy wrote: > In floating-point, usually doing an operation to double precision and then rounding to float gives the right result in float precision. One exception to this is fused multiply add (fma) where "a * b + c" is computed with a single rounding. This requires the equivalent of extra intermediate precision inside the operation. If a float fma is implemented using a double fma rounded to float, for some well-chosen arguments where the final result is near a half-way result in *float*, an incorrect answer will be computed due to double rounding. In more detail, the double result will round up and then the cast to float will round up again whereas a single rounding of the exact answer to float would only round-up once. > > The new float fma implementation does the exact arithmetic using BigDecimal where possible, with guard to handle the non-finite and signed zero IEEE 754 details. This pull request has now been integrated. Changeset: e5304b3a Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/e5304b3a Stats: 32 lines in 2 files changed: 4 ins; 11 del; 17 mod 8253409: Double-rounding possibility in float fma Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2684 From dfuchs at openjdk.java.net Tue Feb 23 19:50:41 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 19:50:41 GMT Subject: RFR: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" [v2] In-Reply-To: <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com> References: <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com> Message-ID: On Tue, 23 Feb 2021 19:35:55 GMT, Naoto Sato wrote: >> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments. LGTM! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2683 From bpb at openjdk.java.net Tue Feb 23 21:08:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 21:08:40 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 18:00:33 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader > > Marked as reviewed by alanb (Reviewer). CSR filed: https://bugs.openjdk.java.net/browse/JDK-8262262. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From rriggs at openjdk.java.net Tue Feb 23 21:36:42 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 23 Feb 2021 21:36:42 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:42:58 GMT, Brian Burkhalter wrote: >> 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader Nice cleanup. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2680 From dfuchs at openjdk.java.net Tue Feb 23 22:18:42 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 23 Feb 2021 22:18:42 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 17:42:58 GMT, Brian Burkhalter wrote: >> 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader src/java.base/share/classes/java/io/PushbackReader.java line 98: > 96: * {@inheritDoc} > 97: */ > 98: public int read(char[] cbuf, int off, int len) throws IOException { Shouldn't you add * @throws IndexOutOfBoundException {@inheritDoc} * @throws IOException {@inheritDoc} here as well? IIRC the global {@inheritDoc} will not add them. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From bpb at openjdk.java.net Tue Feb 23 23:11:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Feb 2021 23:11:40 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 22:12:38 GMT, Daniel Fuchs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader > > src/java.base/share/classes/java/io/PushbackReader.java line 98: > >> 96: * {@inheritDoc} >> 97: */ >> 98: public int read(char[] cbuf, int off, int len) throws IOException { > > Shouldn't you add > > * @throws IndexOutOfBoundException {@inheritDoc} > * @throws IOException {@inheritDoc} > > here as well? IIRC the global {@inheritDoc} will not add them. No. In this case the specification no longer appears in the main method summary but rather under `Methods declared in class java.io.FilterReader` which has a full spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From smarks at openjdk.java.net Tue Feb 23 23:21:39 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 23 Feb 2021 23:21:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: <8jlgZ1Z-C8HB10AVorUwir4hsakTRQRv0x3tIpMf-ZU=.76a15d6d-5485-47ca-86ad-20e8a45528cf@github.com> Message-ID: On Fri, 19 Feb 2021 01:52:51 GMT, liach wrote: >> Maybe it is not correct for UnmodifiableEntrySet::contains to short circuit? What if the implementation was changed to: >> >> `public boolean contains(Object o) { >> if (!(o instanceof Map.Entry)) >> return c.contains(o); //false, NPE, or CCE >> return c.contains( >> new UnmodifiableEntry<>((Map.Entry) o)); >> }` > > This however changes the behavior of unmodifiable maps compared to before; i.e. before for other entry sets, they could not throw exception if the object passed was not map entry; now they can. Yes, it seems reasonable to decouple the `ImmutableCollections` issues from this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From smarks at openjdk.java.net Tue Feb 23 23:34:39 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 23 Feb 2021 23:34:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: <0Q1-b9nmt14hoihSeDUReR8QUMvB8_6VOxg1edY6p_Y=.f3ee334f-fa4a-4eb9-b7b2-acf88022567f@github.com> References: <0Q1-b9nmt14hoihSeDUReR8QUMvB8_6VOxg1edY6p_Y=.f3ee334f-fa4a-4eb9-b7b2-acf88022567f@github.com> Message-ID: On Tue, 23 Feb 2021 16:27:06 GMT, Ian Graves wrote: > Is there any behavior change here that merits a CSR review? Yes. See my comments in the bug report: https://bugs.openjdk.java.net/browse/JDK-6323374?focusedCommentId=14296330&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14296330 There is not only the issue of the identity of the object returned, but the change is also observable in the serialized form. Most people would consider the change (less nesting) to be an improvement, but the change is observable, and as we know any observable behavior can become depended upon by applications. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From smarks at openjdk.java.net Wed Feb 24 02:01:39 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 24 Feb 2021 02:01:39 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: <0Q1-b9nmt14hoihSeDUReR8QUMvB8_6VOxg1edY6p_Y=.f3ee334f-fa4a-4eb9-b7b2-acf88022567f@github.com> Message-ID: On Tue, 23 Feb 2021 23:32:01 GMT, Stuart Marks wrote: >>> > Is there any behavior change here that merits a CSR review? >>> >>> Maybe. The one observable change is that calling `Collections.bar(foo)` with a `foo` that is already a `bar` will return the instance rather than unnecessarily wrap it. This could change semantics in applications inadvertently or deliberately relying on identity. >> >> Yes. The CSR was to consider primarily this case. Probably out of an abundance of caution here. @stuart-marks may have another case to consider. > >> Is there any behavior change here that merits a CSR review? > > Yes. See my comments in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-6323374?focusedCommentId=14296330&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14296330 > > There is not only the issue of the identity of the object returned, but the change is also observable in the serialized form. Most people would consider the change (less nesting) to be an improvement, but the change is observable, and as we know any observable behavior can become depended upon by applications. Code changes all look good. I'm thinking that we should add `@implNote` clauses to all the docs of the affected methods, saying something like "This method may return its argument if it is already unmodifiable." Usually it's reasonable to leave these kinds of behaviors unspecified (and we do so elsewhere) but since this is a change in long-standing behavior, it seems reasonable to highlight it explicitly. I don't think we want to specify it though, because of the issue with ImmutableCollections (as discussed previously) and possible future tuning of behavior regarding the various Set and Map subinterfaces. (For example, C.unmodifiableSet(arg) could return arg if it's an UnmodifiableNavigableSet.) The test seems to have a lot of uncomfortable dependencies, both explicit and implicit, on the various ImmutableCollection and UnmodifiableX implementation classes. Would it be sufficient to test various instances for reference equality and inequality instead? For example, something like var list0 = List.of(); var list1 = Collections.unmodifiableList(list0); var list2 = Collections.unmodifiableList(list1); assertNotSame(list0, list1); assertSame(list1, list2); This would avoid having to write test cases that cover various internal classes. The ImmutableCollections classes have been reorganized in the past, and while we don't have any plans to do so again at the moment, there is always the possibility of it happening again. One could write out all the different cases "by hand" but there are rather a lot of them. It might be fruitful to extract the "wrap once, wrap again, assertNotSame, assertSame" logic into a generic test and drive it somehow with a data provider that provides the base instance and a wrapper function. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From alanb at openjdk.java.net Wed Feb 24 08:54:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 24 Feb 2021 08:54:42 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8261880: Remove static from declarations of Holder nested classes src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67: > 65: private final SinkChannel sink; > 66: > 67: private static class Initializer This one is okay to do. src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java line 51: > 49: * Represents a service provider in the services catalog. > 50: */ > 51: public static final class ServiceProvider { This one is okay to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From andrew at openjdk.java.net Wed Feb 24 15:29:39 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 24 Feb 2021 15:29:39 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v4] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com> Message-ID: <61MUyznDzo9Uonb9DO0SRkhAPtWy3gy9yjY03bJI4iM=.ebc347b1-b549-413c-86cf-a2b053b7a030@github.com> On Fri, 12 Feb 2021 12:49:19 GMT, Severin Gehwolf wrote: >> Setting reviewers to 2 since I want @gnu-andrew to be OK with it too. > > Hi Harold, > >> Thanks for doing this! Sorry for taking so long to review this change. The change looks good. > > Thanks for the review! > >> Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing? > > Done. > >> Also, please don't overwrite the fix for JDK-8257746. > > AFAIK this patch doesn't touch this code. So this should not happen (overwrite of the fix). FWIW, once this is in I intend to propose a patch which adds a regression test for JDK-8257746. It would depend on this change. > > Thanks, > Severin Thanks, this version looks better. Sorry for the delay. I didn't realise you'd replied until I received your e-mail. Not sure where notifications for these git PRs end up. ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From naoto at openjdk.java.net Wed Feb 24 16:26:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 24 Feb 2021 16:26:41 GMT Subject: Integrated: 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato wrote: > Please review the fix to this test case failure that occurs with the usage tracker enabled JRE. This pull request has now been integrated. Changeset: 9d9ad969 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/9d9ad969 Stats: 31 lines in 2 files changed: 16 ins; 7 del; 8 mod 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null" Reviewed-by: joehw, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/2683 From andrew at openjdk.java.net Wed Feb 24 16:27:41 2021 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 24 Feb 2021 16:27:41 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Fri, 12 Feb 2021 12:49:01 GMT, Severin Gehwolf wrote: >> This is an enhancement which solves two issues: >> >> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). >> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. >> >> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to parsing logic of /proc/self/cgroup Marked as reviewed by andrew (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From naoto at openjdk.java.net Wed Feb 24 16:32:45 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 24 Feb 2021 16:32:45 GMT Subject: RFR: 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java [v2] In-Reply-To: References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> Message-ID: On Sat, 20 Feb 2021 02:16:49 GMT, Daniel D. Daugherty wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Limit the exclustion to linux-x64 > > Changes requested by dcubed (Reviewer). As the original issue was resolved, no need to problem list this. ------------- PR: https://git.openjdk.java.net/jdk/pull/2657 From naoto at openjdk.java.net Wed Feb 24 16:32:45 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 24 Feb 2021 16:32:45 GMT Subject: Withdrawn: 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com> Message-ID: On Sat, 20 Feb 2021 00:44:29 GMT, Naoto Sato wrote: > The subject test case is failing under the JMS-enabled environment. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2657 From psandoz at openjdk.java.net Wed Feb 24 17:29:41 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 24 Feb 2021 17:29:41 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7] In-Reply-To: <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> Message-ID: On Fri, 12 Feb 2021 20:27:00 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? >> >> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8252399: Converted JavadocExamples to test Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2544 From sgehwolf at openjdk.java.net Wed Feb 24 17:40:17 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 24 Feb 2021 17:40:17 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v6] In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. Severin Gehwolf 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 10 additional commits since the last revision: - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Add comment to parsing logic of /proc/self/cgroup - Fix jcheck - Add documentation and reduce code running in the critical section - Add some documentation - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1393/files - new: https://git.openjdk.java.net/jdk/pull/1393/files/078e16db..5d5275e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=04-05 Stats: 29136 lines in 793 files changed: 18085 ins; 6354 del; 4697 mod Patch: https://git.openjdk.java.net/jdk/pull/1393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393 PR: https://git.openjdk.java.net/jdk/pull/1393 From sgehwolf at openjdk.java.net Wed Feb 24 17:40:18 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 24 Feb 2021 17:40:18 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: On Wed, 24 Feb 2021 16:24:32 GMT, Andrew John Hughes wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to parsing logic of /proc/self/cgroup > > Marked as reviewed by andrew (Reviewer). @gnu-andrew Thanks for the review! I'll retest and then integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From smarks at openjdk.java.net Wed Feb 24 19:28:42 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 24 Feb 2021 19:28:42 GMT Subject: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7] In-Reply-To: <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com> <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com> Message-ID: On Fri, 12 Feb 2021 20:27:00 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ? >> >> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375). >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8252399: Converted JavadocExamples to test Marked as reviewed by smarks (Reviewer). src/java.base/share/classes/java/util/stream/Stream.java line 410: > 408: * > 409: * public static void main(String[] args) { > 410: * var nestedList = ...; I think it would be good to expand the RHS to use what you use in the test, namely var nestedList = List.of(1, List.of(2, List.of(3, 4)), 5); That would clarify the example quite a bit. Similar for the numbers example above. src/java.base/share/classes/java/util/stream/Stream.java line 414: > 412: * } > 413: * } > 414: * } I'd suggest putting a comment somewhere outside the javadoc that points to the test and has a statement similar to the one in the test, about keeping the example here in synch with the test. I'm not sure what the best way is to do this though. It probably cannot be after the javadoc comment, because the javadoc comment needs to be immediately prior to the method declaration. Maybe a // comment above the doc comment? ------------- PR: https://git.openjdk.java.net/jdk/pull/2544 From sgehwolf at openjdk.java.net Wed Feb 24 19:42:40 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 24 Feb 2021 19:42:40 GMT Subject: Integrated: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: <4LRVddMlQLbwuj3ucT_svgTklw2_BA9X_9fk4hfraW0=.57849a24-52e5-47a8-a79f-1e783678f0f4@github.com> On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf wrote: > This is an enhancement which solves two issues: > > 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot). > 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass. This pull request has now been integrated. Changeset: a50725db Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/a50725db Stats: 596 lines in 5 files changed: 323 ins; 144 del; 129 mod 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection Reviewed-by: hseigel, andrew ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From sgehwolf at openjdk.java.net Wed Feb 24 19:42:39 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 24 Feb 2021 19:42:39 GMT Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection [v5] In-Reply-To: References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com> Message-ID: <6B8DAqhpPjrUXnner51bG8C3JqkOugul-vJzfj2T_ho=.eec814fb-e9c7-401f-96b8-ad327d123801@github.com> On Wed, 24 Feb 2021 17:37:13 GMT, Severin Gehwolf wrote: >> Marked as reviewed by andrew (Reviewer). > > @gnu-andrew Thanks for the review! I'll retest and then integrate. Tests look good on my end. Also this check passed all Linux tests (it's a no-op everywhere else): https://github.com/jerboaa/jdk/actions/runs/596859548 ------------- PR: https://git.openjdk.java.net/jdk/pull/1393 From mandy.chung at oracle.com Wed Feb 24 19:54:53 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Feb 2021 11:54:53 -0800 Subject: JDK-8262003: Class.arrayType should not throw IllegalArgumentException In-Reply-To: References: Message-ID: <607274ef-649f-ed9e-8500-5ec518edea91@oracle.com> Hi Johannes, Changing Class::arrayType to throw ISA makes sense to me. ? I think `TypeDescriptor.ofField::arrayType` spec should also be updated to throw ISA to follow what JVM checks for array dimension because it's a static constraint check [1] (rather than a resolution error) for `anewarray` instruction to create an array no more than 255 dimensions. The CSR looks okay.? I agree that the compatibility risk is low. I'd like to review PR along with CSR together. Mandy [1] https://docs.oracle.com/javase/specs/jvms/se15/html/jvms-4.html#jvms-4.9.1 On 2/23/21 6:38 AM, Johannes Kuhn wrote: > I want to learn about writing a CSR, and need a sponsor teaching me > the ropes. > > ---- > > Bug: https://bugs.openjdk.java.net/browse/JDK-8262003 > > Currently, Class.arrayType() will throw an IllegalArgumentException if > the maximum number of dimensions will be exceeded. > > Throwing an IllegalArgumentException from a method that doesn't take > an argument is, at least, strange. > > Therefore I would like to update the specification to allow this > method to throw an IllegalStateException, similar to what > ClassDesc.arrayType() does. > > ---- > > The current plan is: > > * Create a CSR detailing the spec changes: > https://bugs.openjdk.java.net/browse/JDK-8262211 > * Surround the code with a try-catch block. Checking for the error > case is hard, and somewhat rare, so I think this is appropriate. > * Copy the @throws javadoc line from ClassDesc.arrayType to > Class.arrayType > > But there are a few questions I would love to get the answer on: > > * Both Class.arrayType() and ClassDesc.arrayType() are specified by > TypeDescriptor.OfField. Should the specification of > TypeDescriptor.OfField.arrayType() changed as well? > * Is the draft of my CSR fine? Should I add some details, or omit > things? Rephrase things? > > In advance, thanks for any support and feedback on this. > > - Johannes From isipka at openjdk.java.net Wed Feb 24 20:30:52 2021 From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 24 Feb 2021 20:30:52 GMT Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v12] In-Reply-To: References: Message-ID: <79IEaw2d27o6FduhyJb17bk1RbPEem-x_2nNPIp-DZk=.ea9747cd-35f2-4651-b036-931e794f6b6d@github.com> > Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. Ivan ?ipka has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - 8166026: Refactor java/lang shell tests to java - ... and 1 more: https://git.openjdk.java.net/jdk/compare/a50725db...ad387755 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=11 Stats: 442 lines in 6 files changed: 137 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577 From jai.forums2013 at gmail.com Thu Feb 25 03:56:31 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 25 Feb 2021 09:26:31 +0530 Subject: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream? Message-ID: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> The javadoc of InputStream#readAllBytes() states[1] that it reads all the remaining bytes of the stream. The java.util.zip.ZipInputStream doesn't override this method and thus "inherits" this javadoc. The implementation of InputStream#readAllBytes() ultimately ends up calling ZipInputStream#read()[2], so the implementation correctly reads only till the end of the current ZipEntry and not the entire ZipInputStream. However, because the javadoc gets inherited, reading any code like the following doesn't make it clear that it's only reading till the end of the current entry: zis = ... // ZipInputStream while ((e = zis.getNextEntry()) != null) { ??? String name = e.getName(); ??? zis.readAllBytes(); // gives an impression that all bytes of the stream are read ??? ... } Should the ZipInputStream override the readAllBytes(), just so as to add a very specific javadoc to this method which explains that it reads only till the end of current entry and other related semantics? Perhaps the same should be done for ZipInputStream#readNBytes(...)? [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#readAllBytes() [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/zip/ZipInputStream.html#read(byte%5B%5D,int,int) -Jaikiran From cjplummer at openjdk.java.net Thu Feb 25 03:59:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 25 Feb 2021 03:59:56 GMT Subject: RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread Message-ID: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com> This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up. ------------- Commit messages: - Fix @bug - Add JStackStressTest Changes: https://git.openjdk.java.net/jdk/pull/2720/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2720&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262271 Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2720/head:pull/2720 PR: https://git.openjdk.java.net/jdk/pull/2720 From david.holmes at oracle.com Thu Feb 25 05:20:11 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Feb 2021 15:20:11 +1000 Subject: RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread In-Reply-To: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com> References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com> Message-ID: <676fa12d-d49c-215a-64c7-4f054364682a@oracle.com> Hi Chris, On 25/02/2021 1:59 pm, Chris Plummer wrote: > This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up. Sorry but I don't see how this ensures it runs jstack as the jshell is starting up, the startup could be complete before even one jstack gets issued. Cheers, David > ------------- > > Commit messages: > - Fix @bug > - Add JStackStressTest > > Changes: https://git.openjdk.java.net/jdk/pull/2720/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2720&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8262271 > Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/2720.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2720/head:pull/2720 > > PR: https://git.openjdk.java.net/jdk/pull/2720 > From cjplummer at openjdk.java.net Thu Feb 25 07:03:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 25 Feb 2021 07:03:40 GMT Subject: RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread In-Reply-To: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com> References: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@github.com> Message-ID: <_K-vQe2ii1xQ6eUI1tlrMr1Jzln35Enmb_wO_XIFc4w=.9e23582a-2fcf-4044-bd97-d6c653b200d3@github.com> On Thu, 25 Feb 2021 03:54:35 GMT, Chris Plummer wrote: > This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up. > Sorry but I don't see how this ensures it runs jstack as the jshell is > starting up, the startup could be complete before even one jstack gets > issued. My observation is that at least the main thread has a different stack trace on each iteration. Also, each iteration takes progressively longer as jshell starts up. Although I don't fully understand the reason why, I think it's related to [JDK-8262098](https://bugs.openjdk.java.net/browse/JDK-8262098). Possibly the larger the program gets, the more SA needs to page in, even though you would think jstack would not need to touch that many pages. In any case, this is an indication that the program is changing its state. ------------- PR: https://git.openjdk.java.net/jdk/pull/2720 From mbaesken at openjdk.java.net Thu Feb 25 08:57:43 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 25 Feb 2021 08:57:43 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v2] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Tue, 23 Feb 2021 19:24:31 GMT, Alan Bateman wrote: > This function is "optionally report, optionally fclose, and then exit". Have you tried reducing it to reportAndExit and fclose inline in expandArgFile to avoid it doing 3 things? hi Alan , thanks for your remark , I did not do that because I would need to copy both lines (fclose + exit) to all callers. On the other hand I wonder - wouldn't it be possible to avoid the fclose before the exit(1) ? I assume the closing is done on exit anyway ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From github.com+10835776+stsypanov at openjdk.java.net Thu Feb 25 11:07:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 25 Feb 2021 11:07:47 GMT Subject: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2] In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8261880: Remove static from declarations of Holder nested classes > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67: > >> 65: private final SinkChannel sink; >> 66: >> 67: private static class Initializer > > This one is okay to do. Thanks for review! Could you review the rest of the code and approve this PR, if it's fine? ------------- PR: https://git.openjdk.java.net/jdk/pull/2589 From ewhelan at openjdk.java.net Thu Feb 25 12:08:50 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Thu, 25 Feb 2021 12:08:50 GMT Subject: Integrated: 8252883: AccessDeniedException caused by delayed file deletion on Windows In-Reply-To: References: Message-ID: On Mon, 15 Feb 2021 10:39:32 GMT, Evan Whelan wrote: > Hi, > > Please review this fix for JDK-8252883. This handles the case when an AccessDeniedException is being thrown on Windows, due to a delay in deleting the lock file it is trying to write to. > > This fix passes all testing. > > Kind regards, > Evan This pull request has now been integrated. Changeset: ebdc80ea Author: Evan Whelan Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/ebdc80ea Stats: 73 lines in 2 files changed: 72 ins; 0 del; 1 mod 8252883: AccessDeniedException caused by delayed file deletion on Windows Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/2572 From asotona at openjdk.java.net Thu Feb 25 13:06:04 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Thu, 25 Feb 2021 13:06:04 GMT Subject: RFR: 8260403: javap should be more robust in the face of invalid class files Message-ID: Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute. New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included. Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: " and continues. Thanks, Adam ------------- Commit messages: - 8260403: javap should be more robust in the face of invalid class files Changes: https://git.openjdk.java.net/jdk/pull/2724/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2724&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260403 Stats: 165 lines in 3 files changed: 164 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2724/head:pull/2724 PR: https://git.openjdk.java.net/jdk/pull/2724 From alanb at openjdk.java.net Thu Feb 25 14:06:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 25 Feb 2021 14:06:39 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v2] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Thu, 25 Feb 2021 08:54:48 GMT, Matthias Baesken wrote: >> This function is "optionally report, optionally fclose, and then exit". Have you tried reducing it to reportAndExit and fclose inline in expandArgFile to avoid it doing 3 things? > >> This function is "optionally report, optionally fclose, and then exit". Have you tried reducing it to reportAndExit and fclose inline in expandArgFile to avoid it doing 3 things? > > hi Alan , thanks for your remark , I did not do that because I would need to copy both lines (fclose + exit) to all callers. > On the other hand I wonder - wouldn't it be possible to avoid the fclose before the exit(1) ? > I assume the closing is done on exit anyway ? That sounds okay to me, the process is exiting, as you say. ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From Alan.Bateman at oracle.com Thu Feb 25 14:25:30 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Feb 2021 14:25:30 +0000 Subject: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream? In-Reply-To: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> References: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> Message-ID: <0e1dc882-427e-5bc3-1695-c56c12be90c4@oracle.com> On 25/02/2021 03:56, Jaikiran Pai wrote: > : > > Should the ZipInputStream override the readAllBytes(), just so as to > add a very specific javadoc to this method which explains that it > reads only till the end of current entry and other related semantics? > Perhaps the same should be done for ZipInputStream#readNBytes(...)? Make sense to avoid any confusion and also to do the readNBytes methods at the same time. -Alan From info at j-kuhn.de Thu Feb 25 14:52:38 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Thu, 25 Feb 2021 15:52:38 +0100 Subject: JDK-8262003: Class.arrayType should not throw IllegalArgumentException In-Reply-To: <607274ef-649f-ed9e-8500-5ec518edea91@oracle.com> References: <607274ef-649f-ed9e-8500-5ec518edea91@oracle.com> Message-ID: <9d8191f9-8509-2096-21aa-f99455f9741a@j-kuhn.de> Thanks Mandy. Will amend the CSR to cover TypeDescriptor.OfField::arrayType as well, and create a patch. Where should I put the tests? Didn't find any tests that exercise Class::arrayType in test/jdk/java/lang/. Any wishes for tests that I should add w.r.t. Class::arrayType? - Johannes On 24-Feb-21 20:54, Mandy Chung wrote: > Hi Johannes, > > Changing Class::arrayType to throw ISA makes sense to me. ? I think > `TypeDescriptor.ofField::arrayType` spec should also be updated to throw > ISA to follow what JVM checks for array dimension because it's a static > constraint check [1] (rather than a resolution error) for `anewarray` > instruction to create an array no more than 255 dimensions. > > The CSR looks okay.? I agree that the compatibility risk is low. > > I'd like to review PR along with CSR together. > > Mandy > [1] > https://docs.oracle.com/javase/specs/jvms/se15/html/jvms-4.html#jvms-4.9.1 > > On 2/23/21 6:38 AM, Johannes Kuhn wrote: >> I want to learn about writing a CSR, and need a sponsor teaching me >> the ropes. >> >> ---- >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8262003 >> >> Currently, Class.arrayType() will throw an IllegalArgumentException if >> the maximum number of dimensions will be exceeded. >> >> Throwing an IllegalArgumentException from a method that doesn't take >> an argument is, at least, strange. >> >> Therefore I would like to update the specification to allow this >> method to throw an IllegalStateException, similar to what >> ClassDesc.arrayType() does. >> >> ---- >> >> The current plan is: >> >> * Create a CSR detailing the spec changes: >> https://bugs.openjdk.java.net/browse/JDK-8262211 >> * Surround the code with a try-catch block. Checking for the error >> case is hard, and somewhat rare, so I think this is appropriate. >> * Copy the @throws javadoc line from ClassDesc.arrayType to >> Class.arrayType >> >> But there are a few questions I would love to get the answer on: >> >> * Both Class.arrayType() and ClassDesc.arrayType() are specified by >> TypeDescriptor.OfField. Should the specification of >> TypeDescriptor.OfField.arrayType() changed as well? >> * Is the draft of my CSR fine? Should I add some details, or omit >> things? Rephrase things? >> >> In advance, thanks for any support and feedback on this. >> >> - Johannes > From lance.andersen at oracle.com Thu Feb 25 15:34:35 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 25 Feb 2021 15:34:35 +0000 Subject: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream? In-Reply-To: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> References: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> Message-ID: Hi Jaikiran, Yes I believe this makes sense. It would also require a CSR. I can login a bug if you do not have access to do so. Best Lance On Feb 24, 2021, at 10:56 PM, Jaikiran Pai > wrote: The javadoc of InputStream#readAllBytes() states[1] that it reads all the remaining bytes of the stream. The java.util.zip.ZipInputStream doesn't override this method and thus "inherits" this javadoc. The implementation of InputStream#readAllBytes() ultimately ends up calling ZipInputStream#read()[2], so the implementation correctly reads only till the end of the current ZipEntry and not the entire ZipInputStream. However, because the javadoc gets inherited, reading any code like the following doesn't make it clear that it's only reading till the end of the current entry: zis = ... // ZipInputStream while ((e = zis.getNextEntry()) != null) { String name = e.getName(); zis.readAllBytes(); // gives an impression that all bytes of the stream are read ... } Should the ZipInputStream override the readAllBytes(), just so as to add a very specific javadoc to this method which explains that it reads only till the end of current entry and other related semantics? Perhaps the same should be done for ZipInputStream#readNBytes(...)? [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#readAllBytes() [2] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/zip/ZipInputStream.html#read(byte%5B%5D,int,int) -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jai.forums2013 at gmail.com Thu Feb 25 15:35:35 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 25 Feb 2021 21:05:35 +0530 Subject: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream? In-Reply-To: References: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> Message-ID: <7c84a153-0cd2-fc60-a48f-3c2d12b2c325@gmail.com> Thank you Lance and Alan. I do have access to JBS, I'll file one tomorrow with the details. -Jaikiran On 25/02/21 9:04 pm, Lance Andersen wrote: > Hi Jaikiran, > > Yes I believe this makes sense. > > It would also require a CSR. > > I can login a bug if you do not have access to do so. > > Best > Lance > >> On Feb 24, 2021, at 10:56 PM, Jaikiran Pai > > wrote: >> >> The javadoc of InputStream#readAllBytes() states[1] that it reads all >> the remaining bytes of the stream. The java.util.zip.ZipInputStream >> doesn't override this method and thus "inherits" this javadoc. The >> implementation of InputStream#readAllBytes() ultimately ends up >> calling ZipInputStream#read()[2], so the implementation correctly >> reads only till the end of the current ZipEntry and not the entire >> ZipInputStream. However, because the javadoc gets inherited, reading >> any code like the following doesn't make it clear that it's only >> reading till the end of the current entry: >> >> zis = ... // ZipInputStream >> while ((e = zis.getNextEntry()) != null) { >> ??? String name = e.getName(); >> ??? zis.readAllBytes(); // gives an impression that all bytes of the >> stream are read >> ??? ... >> } >> >> Should the ZipInputStream override the readAllBytes(), just so as to >> add a very specific javadoc to this method which explains that it >> reads only till the end of current entry and other related semantics? >> Perhaps the same should be done for ZipInputStream#readNBytes(...)? >> >> >> [1] >> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#readAllBytes() >> >> [2] >> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/zip/ZipInputStream.html#read(byte%5B%5D,int,int) >> >> >> -Jaikiran >> > > > > > Lance Andersen| Principal?Member of Technical Staff?| +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From vromero at openjdk.java.net Thu Feb 25 15:38:46 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 25 Feb 2021 15:38:46 GMT Subject: RFR: 8260403: javap should be more robust in the face of invalid class files In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote: > Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute. > New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included. > Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: " and continues. > > Thanks, > Adam lgtm! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2724 From mbaesken at openjdk.java.net Thu Feb 25 15:40:00 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 25 Feb 2021 15:40:00 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v3] In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove fclose before exit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2692/files - new: https://git.openjdk.java.net/jdk/pull/2692/files/8b106a14..b5eeca4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692 PR: https://git.openjdk.java.net/jdk/pull/2692 From shade at openjdk.java.net Thu Feb 25 15:40:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 25 Feb 2021 15:40:45 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Thu, 18 Feb 2021 19:31:02 GMT, Attila Szegedi wrote: >> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" > > Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The good test would be trying with all current GCs (Serial, Parallel, G1, Shenandoah, ZGC): make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC Also, make sure that GH actions are able to run this test. You probably need to enable the workflow here -- https://github.com/szegedi/jdk/actions -- and then trigger the workflow manually on your branch (or push another commit). Then "Checks" tab would show the results. test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 28: > 26: * @bug 8198540 > 27: * @summary Test TypeConverterFactory is not leaking method handles > 28: * @run main/othervm -Xmx4M TypeConverterFactoryMemoryLeakTest I think `-Xmx4m` is risking it on some platforms that cannot go that low heap. Maybe do 128M, and bulk up the test allocations, so that GC definitely triggers? test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 79: > 77: > 78: public static void main(String[] args) { > 79: for (int count = 0; count < MAX_ITERATIONS; ++count) { Here and later: use postfix `count++`, regular style? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2617 From adam.sotona at oracle.com Thu Feb 25 15:58:47 2021 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 25 Feb 2021 15:58:47 +0000 Subject: 8260403: javap should be more robust in the face of invalid class files Message-ID: <537EE7B0-8993-4F51-B595-2D533D6B2261@oracle.com> Hi Vicente, thanks for the review. May I ask you also to /sponsor this PR? Thanks again, Adam ?On 25/02/2021, 16:39, "core-libs-dev on behalf of Vicente Romero" wrote: On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote: > Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute. > New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included. > Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: " and continues. > > Thanks, > Adam lgtm! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2724 From asotona at openjdk.java.net Thu Feb 25 16:05:44 2021 From: asotona at openjdk.java.net (Adam Sotona) Date: Thu, 25 Feb 2021 16:05:44 GMT Subject: Integrated: 8260403: javap should be more robust in the face of invalid class files In-Reply-To: References: Message-ID: <_1YneenbAHwp4WWtFeBT9CzGi1POxFNQD1bti_Mblvc=.31bc4194-bf92-4756-ae70-20bab423875b@github.com> On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote: > Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute. > New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included. > Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: " and continues. > > Thanks, > Adam This pull request has now been integrated. Changeset: 7d4f60b1 Author: Adam Sotona Committer: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/7d4f60b1 Stats: 165 lines in 3 files changed: 164 ins; 0 del; 1 mod 8260403: javap should be more robust in the face of invalid class files Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/2724 From clanger at openjdk.java.net Thu Feb 25 16:12:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 25 Feb 2021 16:12:40 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v3] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Thu, 25 Feb 2021 15:40:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Remove fclose before exit Changes requested by clanger (Reviewer). src/java.base/share/native/libjli/args.c line 378: > 376: if (st.st_size > MAX_ARGF_SIZE) { > 377: JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); > 378: reportAndExit(NULL, NULL); This should be just one statement, reportAndExit(CFG_ERROR10, MAX_ARGF_SIZE); or? src/java.base/share/native/libjli/args.c line 358: > 356: > 357: static void reportAndExit(const char* fmt, const char* arg) { > 358: if (fmt != NULL) JLI_ReportMessage(fmt, arg); the if (fmt != NULL) check wouldn't be necessary here if you fix the other location with reportAndExit(NULL, NULL), I think ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From bpb at openjdk.java.net Thu Feb 25 16:26:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Feb 2021 16:26:40 GMT Subject: RFR: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 18:00:33 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258444: Explcitly inherit IOOBE in {Filter,InputStream}Reader > > Marked as reviewed by alanb (Reviewer). @AlanBateman, @dfuch, @RogerRiggs thanks for the reviews here and @jddarcy for approving the CSR! ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From bpb at openjdk.java.net Thu Feb 25 16:26:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Feb 2021 16:26:41 GMT Subject: Integrated: 8258444: Clean up specifications of java.io.Reader.read(char[], int, int) in subclass overrides In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 23:27:19 GMT, Brian Burkhalter wrote: > 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides This pull request has now been integrated. Changeset: 5a9b7010 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/5a9b7010 Stats: 156 lines in 9 files changed: 41 ins; 55 del; 60 mod 8258444: Clean up specifications of java.io.Reader.read(char[],int,int) in subclass overrides Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/2680 From sgehwolf at openjdk.java.net Thu Feb 25 16:33:05 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 25 Feb 2021 16:33:05 GMT Subject: RFR: 8262379: Add regression test for JDK-8257746 Message-ID: Fails prior the patch of JDK-8257746, passes after. As expected. Thoughts? ------------- Commit messages: - 8262379: Add regression test for JDK-8257746 Changes: https://git.openjdk.java.net/jdk/pull/2725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262379 Stats: 56 lines in 1 file changed: 56 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2725/head:pull/2725 PR: https://git.openjdk.java.net/jdk/pull/2725 From mbaesken at openjdk.java.net Thu Feb 25 16:44:00 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 25 Feb 2021 16:44:00 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v4] In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify coding ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2692/files - new: https://git.openjdk.java.net/jdk/pull/2692/files/b5eeca4f..39faea43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692 PR: https://git.openjdk.java.net/jdk/pull/2692 From mbaesken at openjdk.java.net Thu Feb 25 16:44:01 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 25 Feb 2021 16:44:01 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v3] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: <5CAFLuVTICUvxembPiDNCEJotTQbohuHDb5c-u5kL1w=.cb96147e-3ba2-418e-83bb-deb0edd2e46b@github.com> On Thu, 25 Feb 2021 16:07:36 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove fclose before exit > > src/java.base/share/native/libjli/args.c line 378: > >> 376: if (st.st_size > MAX_ARGF_SIZE) { >> 377: JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); >> 378: reportAndExit(NULL, NULL); > > This should be just one statement, > reportAndExit(CFG_ERROR10, MAX_ARGF_SIZE); > or? I think that did not work because it does not fit the param types of reportAndExit but I can simplify it otherwise. ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From alanb at openjdk.java.net Thu Feb 25 17:00:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 25 Feb 2021 17:00:40 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v4] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Thu, 25 Feb 2021 16:44:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify coding Thanks for the updates, the latest looks clean to me. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2692 From psandoz at openjdk.java.net Thu Feb 25 17:25:40 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 25 Feb 2021 17:25:40 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu wrote: > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 src/hotspot/share/prims/vectorSupport.cpp line 368: > 366: if (java_lang_Class::is_primitive(mirror)) { > 367: BasicType bt = java_lang_Class::primitive_type(mirror); > 368: int min_lane_count = 64 / type2aelembytes(bt); I am uncertain of the units here. Is the numerator in bits and the denominator in bytes? ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From gziemski at openjdk.java.net Thu Feb 25 17:34:58 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 25 Feb 2021 17:34:58 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18] In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 12:36:10 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: > > - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos > - Re-do safefetch.hpp > - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos > - stubRoutines.inline.hpp -> safefetch.hpp > - Update copyrights > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline > - Extract SafeFetch32/N to stubRoutines.inline.hpp > - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" > > This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. > - Merge pull request #9 from VladimirKempik/pull/2200 > > Removed unused variables > - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From clanger at openjdk.java.net Thu Feb 25 17:49:44 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 25 Feb 2021 17:49:44 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v3] In-Reply-To: <5CAFLuVTICUvxembPiDNCEJotTQbohuHDb5c-u5kL1w=.cb96147e-3ba2-418e-83bb-deb0edd2e46b@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> <5CAFLuVTICUvxembPiDNCEJotTQbohuHDb5c-u5kL1w=.cb96147e-3ba2-418e-83bb-deb0edd2e46b@github.com> Message-ID: On Thu, 25 Feb 2021 16:39:25 GMT, Matthias Baesken wrote: >> src/java.base/share/native/libjli/args.c line 378: >> >>> 376: if (st.st_size > MAX_ARGF_SIZE) { >>> 377: JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE); >>> 378: reportAndExit(NULL, NULL); >> >> This should be just one statement, >> reportAndExit(CFG_ERROR10, MAX_ARGF_SIZE); >> or? > > I think that did not work because it does not fit the param types of reportAndExit but I can simplify it otherwise. Ah, I see. Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice now, wouldn't it be less convoluted if you use JLI_ReportMessage(...); exit(1); inline in both places? ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From mandy.chung at oracle.com Thu Feb 25 18:24:52 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Feb 2021 10:24:52 -0800 Subject: JDK-8262003: Class.arrayType should not throw IllegalArgumentException In-Reply-To: <9d8191f9-8509-2096-21aa-f99455f9741a@j-kuhn.de> References: <607274ef-649f-ed9e-8500-5ec518edea91@oracle.com> <9d8191f9-8509-2096-21aa-f99455f9741a@j-kuhn.de> Message-ID: On 2/25/21 6:52 AM, Johannes Kuhn wrote: > Thanks Mandy. > > Will amend the CSR to cover TypeDescriptor.OfField::arrayType as well, > and create a patch. > > Where should I put the tests? > Didn't find any tests that exercise Class::arrayType in > test/jdk/java/lang/. > Any wishes for tests that I should add w.r.t. Class::arrayType? > Yes, I suggest to put it under test/jdk/java/lang/Class/arrayType. Mandy > - Johannes > > On 24-Feb-21 20:54, Mandy Chung wrote: >> Hi Johannes, >> >> Changing Class::arrayType to throw ISA makes sense to me. ? I think >> `TypeDescriptor.ofField::arrayType` spec should also be updated to >> throw ISA to follow what JVM checks for array dimension because it's >> a static constraint check [1] (rather than a resolution error) for >> `anewarray` instruction to create an array no more than 255 dimensions. >> >> The CSR looks okay.? I agree that the compatibility risk is low. >> >> I'd like to review PR along with CSR together. >> >> Mandy >> [1] >> https://docs.oracle.com/javase/specs/jvms/se15/html/jvms-4.html#jvms-4.9.1 >> >> On 2/23/21 6:38 AM, Johannes Kuhn wrote: >>> I want to learn about writing a CSR, and need a sponsor teaching me >>> the ropes. >>> >>> ---- >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8262003 >>> >>> Currently, Class.arrayType() will throw an IllegalArgumentException >>> if the maximum number of dimensions will be exceeded. >>> >>> Throwing an IllegalArgumentException from a method that doesn't take >>> an argument is, at least, strange. >>> >>> Therefore I would like to update the specification to allow this >>> method to throw an IllegalStateException, similar to what >>> ClassDesc.arrayType() does. >>> >>> ---- >>> >>> The current plan is: >>> >>> * Create a CSR detailing the spec changes: >>> https://bugs.openjdk.java.net/browse/JDK-8262211 >>> * Surround the code with a try-catch block. Checking for the error >>> case is hard, and somewhat rare, so I think this is appropriate. >>> * Copy the @throws javadoc line from ClassDesc.arrayType to >>> Class.arrayType >>> >>> But there are a few questions I would love to get the answer on: >>> >>> * Both Class.arrayType() and ClassDesc.arrayType() are specified by >>> TypeDescriptor.OfField. Should the specification of >>> TypeDescriptor.OfField.arrayType() changed as well? >>> * Is the draft of my CSR fine? Should I add some details, or omit >>> things? Rephrase things? >>> >>> In advance, thanks for any support and feedback on this. >>> >>> - Johannes >> From herrick at openjdk.java.net Thu Feb 25 21:20:51 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 25 Feb 2021 21:20:51 GMT Subject: RFR: JDK-8261839: Error creating runtime package on macos without =?UTF-8?B?bWFjLXBhY2vigKY=?= Message-ID: ?age-identifier ------------- Commit messages: - JDK-8261839: Error creating runtime package on macos without mac-package-identifier Changes: https://git.openjdk.java.net/jdk/pull/2730/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261839 Stats: 24 lines in 4 files changed: 8 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2730/head:pull/2730 PR: https://git.openjdk.java.net/jdk/pull/2730 From asemenyuk at openjdk.java.net Thu Feb 25 21:40:44 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 25 Feb 2021 21:40:44 GMT Subject: RFR: JDK-8261839: Error creating runtime package on macos without =?UTF-8?B?bWFjLXBhY2vigKY=?= In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick wrote: > ?age-identifier Marked as reviewed by asemenyuk (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2730 From asemenyuk at openjdk.java.net Thu Feb 25 21:40:44 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 25 Feb 2021 21:40:44 GMT Subject: RFR: JDK-8261839: Error creating runtime package on macos without =?UTF-8?B?bWFjLXBhY2vigKY=?= In-Reply-To: References: Message-ID: <0fWSr2fCsU7MvctZmElzFVSkMOWOfP5euOgeKSJcg-A=.3864e580-a366-4ead-8d3d-4f66de6ce034@github.com> On Thu, 25 Feb 2021 21:36:48 GMT, Alexey Semenyuk wrote: >> ?age-identifier > > Marked as reviewed by asemenyuk (Committer). Nice to have runtime packaging implemented on all supported platforms! ------------- PR: https://git.openjdk.java.net/jdk/pull/2730 From joehw at openjdk.java.net Thu Feb 25 22:09:51 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 25 Feb 2021 22:09:51 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits Message-ID: Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. ------------- Commit messages: - 8261670: Add javadoc for the XML processing limits Changes: https://git.openjdk.java.net/jdk/pull/2732/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261670 Stats: 87 lines in 1 file changed: 81 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2732/head:pull/2732 PR: https://git.openjdk.java.net/jdk/pull/2732 From naoto at openjdk.java.net Thu Feb 25 22:36:41 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 25 Feb 2021 22:36:41 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:04:41 GMT, Joe Wang wrote: > Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. src/java.xml/share/classes/module-info.java line 231: > 229: * > 230: * A positive integer. A value less than or equal to 0 indicates no limit. > 231: * If the value is not an integer, a NumericFormatException is thrown. Is it a ```NumberFormatException```? Also, @link might be useful here. src/java.xml/share/classes/module-info.java line 233: > 231: * If the value is not an integer, a NumericFormatException is thrown. > 232: * > 233: * 64000 There are other ```Default``` ids in other rows. Should they be distinct? Or rather needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/2732 From joehw at openjdk.java.net Thu Feb 25 22:39:40 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 25 Feb 2021 22:39:40 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits In-Reply-To: References: Message-ID: <-BcUcgNeJKSTaBIsTL8xxRPkjCoZXNFb-wnUoZfL2SU=.bb00a631-a39a-40f9-b8ed-f5006937afc4@github.com> On Thu, 25 Feb 2021 22:28:43 GMT, Naoto Sato wrote: >> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. > > src/java.xml/share/classes/module-info.java line 231: > >> 229: * >> 230: * A positive integer. A value less than or equal to 0 indicates no limit. >> 231: * If the value is not an integer, a NumericFormatException is thrown. > > Is it a ```NumberFormatException```? Also, @link might be useful here. Oh my, the typo has been in the tutorial all this time! It's NumberFormatException indeed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2732 From joehw at openjdk.java.net Thu Feb 25 22:42:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 25 Feb 2021 22:42:43 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:33:02 GMT, Naoto Sato wrote: >> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. > > src/java.xml/share/classes/module-info.java line 233: > >> 231: * If the value is not an integer, a NumericFormatException is thrown. >> 232: * >> 233: * 64000 > > There are other ```Default``` ids in other rows. Should they be distinct? Or rather needed? True, not needed. Will remove, and also look at other copy&paste-d ids. ------------- PR: https://git.openjdk.java.net/jdk/pull/2732 From jjg at openjdk.java.net Thu Feb 25 22:46:49 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 25 Feb 2021 22:46:49 GMT Subject: RFR: JDK-8262428: doclint warnings in java.xml module Message-ID: Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. ------------- Commit messages: - JDK-8262428: doclint warnings in java.xml module Changes: https://git.openjdk.java.net/jdk/pull/2733/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2733&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262428 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2733.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2733/head:pull/2733 PR: https://git.openjdk.java.net/jdk/pull/2733 From bpb at openjdk.java.net Thu Feb 25 22:51:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Feb 2021 22:51:39 GMT Subject: RFR: JDK-8262428: doclint warnings in java.xml module In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2733 From lancea at openjdk.java.net Thu Feb 25 22:56:37 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 25 Feb 2021 22:56:37 GMT Subject: RFR: JDK-8262428: doclint warnings in java.xml module In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. Looks OK. Joe is in the process of updating module-info so perhaps this can be combined with his change? ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2733 From naoto at openjdk.java.net Thu Feb 25 23:04:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 25 Feb 2021 23:04:44 GMT Subject: RFR: JDK-8262428: doclint warnings in java.xml module In-Reply-To: References: Message-ID: <6KdHNpxjP0yJPzQjuokcjxm42OsdKIsCaeVPFxrc1rM=.75e19393-b8bc-4b67-bd3f-4482b1a07c9c@github.com> On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2733 From iris at openjdk.java.net Thu Feb 25 23:08:38 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 25 Feb 2021 23:08:38 GMT Subject: RFR: JDK-8262428: doclint warnings in java.xml module In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2733 From jjg at openjdk.java.net Thu Feb 25 23:42:40 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 25 Feb 2021 23:42:40 GMT Subject: Integrated: JDK-8262428: doclint warnings in java.xml module In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `

      ` tags and an erroneous `` tag, all reported by doclint.. This pull request has now been integrated. Changeset: 059ede0d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/059ede0d Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod 8262428: doclint warnings in java.xml module Reviewed-by: bpb, lancea, naoto, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/2733 From jiefu at openjdk.java.net Thu Feb 25 23:52:06 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 25 Feb 2021 23:52:06 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v2] In-Reply-To: <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> Message-ID: On Thu, 25 Feb 2021 17:23:11 GMT, Paul Sandoz wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> The numerator should be 8 (byte) > > src/hotspot/share/prims/vectorSupport.cpp line 368: > >> 366: if (java_lang_Class::is_primitive(mirror)) { >> 367: BasicType bt = java_lang_Class::primitive_type(mirror); >> 368: int min_lane_count = 64 / type2aelembytes(bt); > > I am uncertain of the units here. Is the numerator in bits and the denominator in bytes? Thanks Paul for your review. Oops, the numerator should be 8 (bytes). Updated. Testing of jdk/incubator/vector (MaxVector=default/8/4 or without C2) is still fine. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Thu Feb 25 23:52:04 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 25 Feb 2021 23:52:04 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v2] In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: The numerator should be 8 (byte) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/09b49f25..724b36d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722 From almatvee at openjdk.java.net Fri Feb 26 00:17:41 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 26 Feb 2021 00:17:41 GMT Subject: RFR: JDK-8261839: Error creating runtime package on macos without =?UTF-8?B?bWFjLXBhY2vigKY=?= In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick wrote: > ?age-identifier Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2730 From psandoz at openjdk.java.net Fri Feb 26 00:33:41 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 26 Feb 2021 00:33:41 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v2] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> Message-ID: On Thu, 25 Feb 2021 23:48:37 GMT, Jie Fu wrote: >> src/hotspot/share/prims/vectorSupport.cpp line 368: >> >>> 366: if (java_lang_Class::is_primitive(mirror)) { >>> 367: BasicType bt = java_lang_Class::primitive_type(mirror); >>> 368: int min_lane_count = 64 / type2aelembytes(bt); >> >> I am uncertain of the units here. Is the numerator in bits and the denominator in bytes? > > Thanks Paul for your review. > > Oops, the numerator should be 8 (bytes). > > Updated. > Testing of jdk/incubator/vector (MaxVector=default/8/4 or without C2) is still fine. > Thanks. Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator? Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From jjg at openjdk.java.net Fri Feb 26 00:45:58 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 26 Feb 2021 00:45:58 GMT Subject: RFR: JDK-8262433: doclint: reference error in module jdk.incubator.foreign Message-ID: Please review a simple fix to ensure that a link reference is resolved and displayed correctly. ------------- Commit messages: - JDK-8262433: doclint: reference error in module jdk.incubator.foreign Changes: https://git.openjdk.java.net/jdk/pull/2739/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262433 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2739/head:pull/2739 PR: https://git.openjdk.java.net/jdk/pull/2739 From bpb at openjdk.java.net Fri Feb 26 00:54:37 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 26 Feb 2021 00:54:37 GMT Subject: RFR: JDK-8262433: doclint: reference error in module jdk.incubator.foreign In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 00:41:18 GMT, Jonathan Gibbons wrote: > Please review a simple fix to ensure that a link reference is resolved and displayed correctly. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2739 From lancea at openjdk.java.net Fri Feb 26 00:54:38 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 26 Feb 2021 00:54:38 GMT Subject: RFR: JDK-8262433: doclint: reference error in module jdk.incubator.foreign In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 00:41:18 GMT, Jonathan Gibbons wrote: > Please review a simple fix to ensure that a link reference is resolved and displayed correctly. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2739 From jjg at openjdk.java.net Fri Feb 26 00:54:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 26 Feb 2021 00:54:38 GMT Subject: Integrated: JDK-8262433: doclint: reference error in module jdk.incubator.foreign In-Reply-To: References: Message-ID: <04hyoE-NEPODrMYCcU9yUwaPKprQ_AsnrcuLpHI88Ps=.9acc9769-9aac-4a58-adb3-0b4e52047d7b@github.com> On Fri, 26 Feb 2021 00:41:18 GMT, Jonathan Gibbons wrote: > Please review a simple fix to ensure that a link reference is resolved and displayed correctly. This pull request has now been integrated. Changeset: fce57656 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/fce57656 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8262433: doclint: reference error in module jdk.incubator.foreign Reviewed-by: bpb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/2739 From jai.forums2013 at gmail.com Fri Feb 26 02:12:26 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 26 Feb 2021 07:42:26 +0530 Subject: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream? In-Reply-To: <7c84a153-0cd2-fc60-a48f-3c2d12b2c325@gmail.com> References: <3bde5f78-43ef-0d18-9fd1-161b961b3cdd@gmail.com> <7c84a153-0cd2-fc60-a48f-3c2d12b2c325@gmail.com> Message-ID: I just created https://bugs.openjdk.java.net/browse/JDK-8262435 to track this. -Jaikiran On 25/02/21 9:05 pm, Jaikiran Pai wrote: > > Thank you Lance and Alan. I do have access to JBS, I'll file one > tomorrow with the details. > > -Jaikiran > > On 25/02/21 9:04 pm, Lance Andersen wrote: >> Hi Jaikiran, >> >> Yes I believe this makes sense. >> >> It would also require a CSR. >> >> I can login a bug if you do not have access to do so. >> >> Best >> Lance >> >>> On Feb 24, 2021, at 10:56 PM, Jaikiran Pai >> > wrote: >>> >>> The javadoc of InputStream#readAllBytes() states[1] that it reads >>> all the remaining bytes of the stream. The >>> java.util.zip.ZipInputStream doesn't override this method and thus >>> "inherits" this javadoc. The implementation of >>> InputStream#readAllBytes() ultimately ends up calling >>> ZipInputStream#read()[2], so the implementation correctly reads only >>> till the end of the current ZipEntry and not the entire >>> ZipInputStream. However, because the javadoc gets inherited, reading >>> any code like the following doesn't make it clear that it's only >>> reading till the end of the current entry: >>> >>> zis = ... // ZipInputStream >>> while ((e = zis.getNextEntry()) != null) { >>> ??? String name = e.getName(); >>> ??? zis.readAllBytes(); // gives an impression that all bytes of the >>> stream are read >>> ??? ... >>> } >>> >>> Should the ZipInputStream override the readAllBytes(), just so as to >>> add a very specific javadoc to this method which explains that it >>> reads only till the end of current entry and other related >>> semantics? Perhaps the same should be done for >>> ZipInputStream#readNBytes(...)? >>> >>> >>> [1] >>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#readAllBytes() >>> >>> [2] >>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/zip/ZipInputStream.html#read(byte%5B%5D,int,int) >>> >>> >>> -Jaikiran >>> >> >> >> >> >> Lance Andersen| Principal?Member of Technical Staff?| +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From jiefu at openjdk.java.net Fri Feb 26 02:19:01 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 26 Feb 2021 02:19:01 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v3] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> Message-ID: On Fri, 26 Feb 2021 00:30:45 GMT, Paul Sandoz wrote: > Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator? Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt). > Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? Ok. But it that case, I'd like to just re-use jdk/incubator/vector/PreferredSpeciesTest.java. > Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ? Fine. Although this bug wouldn't be triggered with -XX:TieredStopAtLevel=x, it can help test with C1. Patch had been updated. Any comments? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Fri Feb 26 02:19:01 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 26 Feb 2021 02:19:01 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v3] In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Update the jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/724b36d4..aa475b0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=01-02 Stats: 59 lines in 2 files changed: 10 ins; 48 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722 From psandoz at openjdk.java.net Fri Feb 26 02:31:39 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 26 Feb 2021 02:31:39 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v3] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> Message-ID: On Fri, 26 Feb 2021 02:16:02 GMT, Jie Fu wrote: >> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator? >> Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? >> Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ? > >> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the numerator? > Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt). > >> Perhaps we should be testing more directly on `VectorShape.S_Max_BIT.vectorBitSize()` and `VectorShape.preferredShape` ? > Ok. > But it that case, I'd like to just re-use jdk/incubator/vector/PreferredSpeciesTest.java. > >> Also, perhaps we can run with C2 disabled, with `-XX:TieredStopAtLevel=3` ? > Fine. > Although this bug wouldn't be triggered with -XX:TieredStopAtLevel=x, it can help test with C1. > > Patch had been updated. > Any comments? > Thanks. Reusing PreferredSpeciesTest is a good idea. I now realize that C2 needs to be compiled out to trigger some other cases. In that case I think we can remove the execution with `-XX:TieredStopAtLevel=x`. The test will get executed with various HotSpot configurations by the test infrastructure, eventually... Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Fri Feb 26 02:38:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 26 Feb 2021 02:38:00 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <8uVq41r6szj6ZIS823AKYsvm1ja29A-YY_3fo7RCyGQ=.e790ca0e-99ca-48e1-b1e1-fee731bdc2c8@github.com> Message-ID: <6aOBlWYEmWHRYJ2YehyBI_AoE5_bA3Hejgdl2yIRt84=.fbffb4ec-3949-4993-8468-c39f5cde3f09@github.com> On Fri, 26 Feb 2021 02:28:55 GMT, Paul Sandoz wrote: > In that case I think we can remove the execution with `-XX:TieredStopAtLevel=x`. Fixed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Fri Feb 26 02:38:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 26 Feb 2021 02:38:00 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Remove -XX:TieredStopAtLevel=3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/aa475b0a..bbe6150c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722 From psandoz at openjdk.java.net Fri Feb 26 03:19:41 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 26 Feb 2021 03:19:41 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu wrote: >> Hi all, >> >> Vector API fails to work when: >> - case 1: MaxVectorSize is set to <=8, or >> - case 2: C2 is disabled >> >> The reason is that {max/preferred} VectorShape initialization fails in both cases. >> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). >> >> Vector API should not depend on C2 to run. >> It should work even there is no JIT compiler since it's a Java-level api. >> So let's fix it. >> >> Testing: >> - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove -XX:TieredStopAtLevel=3 Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From joehw at openjdk.java.net Fri Feb 26 07:06:17 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 26 Feb 2021 07:06:17 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits [v2] In-Reply-To: References: Message-ID: > Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8261670 - 8261670: Add javadoc for the XML processing limits ------------- Changes: https://git.openjdk.java.net/jdk/pull/2732/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=01 Stats: 87 lines in 1 file changed: 81 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2732/head:pull/2732 PR: https://git.openjdk.java.net/jdk/pull/2732 From joehw at openjdk.java.net Fri Feb 26 08:04:02 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 26 Feb 2021 08:04:02 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits [v3] In-Reply-To: References: Message-ID: > Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: s/NumericFormatException/NumberFormatException, remove default id ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2732/files - new: https://git.openjdk.java.net/jdk/pull/2732/files/01695074..3e555d20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=01-02 Stats: 20 lines in 1 file changed: 0 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/2732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2732/head:pull/2732 PR: https://git.openjdk.java.net/jdk/pull/2732 From plevart at openjdk.java.net Fri Feb 26 08:06:40 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 26 Feb 2021 08:06:40 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 15:37:39 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > The good test would be trying with all current GCs (Serial, Parallel, G1, Shenandoah, ZGC): > > make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC > > Also, make sure that GH actions are able to run this test. You probably need to enable the workflow here -- https://github.com/szegedi/jdk/actions -- and then trigger the workflow manually on your branch (or push another commit). Then "Checks" tab would show the results. > > I would like 1st to understand why the MH created in the TestLinker.convertToType is actually GCed at all. > > The whole original issue was about allowing these objects to be GCd smile. > Short story: because all data is scoped to objects created within `makeOne` method. Right, below description helped me understand the "chain of domination - i.e. hard references that keep the BiClassValueRoot (extends ClassValue) reachable". That doesn't explain fully why converters are not GC-ed as soon as the associated BiClassValueRoot is eligible for GC. The secret lies in the implementation of ClassValue... > > Longer story: It is GC'd because its reachability is dominated by the `DynamicLinker` object created on [line 96](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java#L96). It and everything it dominates (`LinkerServicesImpl` object holding the `TypeConverterFactory` object holding the `BiClassValue` objects holding the method handles) become garbage as soon as the method exits. That is not entirely true. What becomes garbage is the objects leading to the BiClassValueRoot (extends ClassValue) instance including the BiClassValueRoot instance. But it is not the ClassValue instance that keeps the associated T value(s) reachable. The associated values are strongly reachable from the associated Class instances. The Class class contains an instance field of type ClassValueMap which is responsible for keeping the associated values. This answers my question why the associated converter is GCed only after 12 new converters are created for the same source/target type pair. It is not because creating new converters would cause memory pressure and consequently trigger GC (I tried adding explicit System.gc() calls and they did not expedite the GCing of the converter). It is because ClassValue logic expunges associated T values from Class.ClassValueMap only at times when it has to re-arrange the map's internal structures and that eventually happens on new inserti ons for the same Class instance and different ClassValue instance. That doesn't mean type converter caching is flawed in any way. It just means that some converters will be retained even though they are practically not "reachable" any more through the mechanism of caching. That doesn't mean that any ClassLoader leaks are possible either. > This works because of the pains I took in `BiClassValue` to ensure we don't leak any of the infrastructural objects through implicit `this$0` outer-class references into the `ClassValue`s. That allows the `ClassValue` objects to be GCd and removed from the classes' class-value mapping. This ordinarily doesn't happen as most `ClassValue` objects are bound to static fields, but in `TypeConverterFactory` the `BiClassValue` instances are specific to the `TypeConverterFactory` instance, so they are expected to be reclaimable by GC if the converter factory itself goes away. > > > And after that, why it is not GCed before 12 invocations to makeOne() are made. > > Because GC is at liberty to delay recognizing an object is phantom reachable? I don't think we need to read too much into this? Correct me if I don't see something. As described above, GC has nothing to do with this "delay". It is caused by the way ClassValue keeps associated values reachable from the associated Class instances (that appear semantically as keys, but in fact it's the other way arround - ClassValue instances are weakly reachable keys and Class instances hold the maps). > > > What would be more interesting to test is to create a converter between a type loaded by a custom (child) ClassLoader and a system type. After that, release all hard references to the custom ClassLoader and see if the converter gets GC-ed as a result. WDYT? > > That does sound like [TypeConverterFactoryRetentionTests.testSystemLoaderToOtherLoader](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java#L118) True, it tests whether the _class loader_ itself gets released, not the converter, but the loader would hardly get released while there's a converter with the class from that loader bound in the parameter signature of its method handle, wouldn't it? Yes, that test is exactly what I was thinking about. > > Regardless, if you think there's a valid use case for this additional test, we can discuss it. I'd rather scope this issue to fixing the flakiness of the tests, so they don't cause trouble with builds and can be backported/added to ongoing backports. > > Thanks for taking time to look into this! I think the tests cover what needs to be covered. I would just iterate the same test over all GC implementations (as Aleksey already suggested) and instead of minimizing the heap size (which could cause problems in some GC implementations as they evolve), insert explicit System.gc() calls in the loops to trigger GC cycles that also process Reference(s). I tried that with all current CG implementations (SerialGC, G1GC, ParallelGC, ZGC and ShenandoahGC) and they all respect System.gc() calls. Even though I increased heap size to 128M, the 1st associated converter always got GCed after 12 new converters were created for the same source/target class pair. ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From mbaesken at openjdk.java.net Fri Feb 26 08:31:00 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 26 Feb 2021 08:31:00 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v5] In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Replace reportAndExit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2692/files - new: https://git.openjdk.java.net/jdk/pull/2692/files/39faea43..2da97d61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=03-04 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2692.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692 PR: https://git.openjdk.java.net/jdk/pull/2692 From mbaesken at openjdk.java.net Fri Feb 26 08:31:01 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 26 Feb 2021 08:31:01 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v3] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> <5CAFLuVTICUvxembPiDNCEJotTQbohuHDb5c-u5kL1w=.cb96147e-3ba2-418e-83bb-deb0edd2e46b@github.com> Message-ID: On Thu, 25 Feb 2021 17:46:42 GMT, Christoph Langer wrote: >> I think that did not work because it does not fit the param types of reportAndExit but I can simplify it otherwise. > > Ah, I see. > Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice now, wouldn't it be less convoluted if you use > JLI_ReportMessage(...); > exit(1); > inline in both places? Yes I agree, see my latest change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From clanger at openjdk.java.net Fri Feb 26 08:34:44 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 26 Feb 2021 08:34:44 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v5] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Replace reportAndExit Looks good now :) ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2692 From alanb at openjdk.java.net Fri Feb 26 08:41:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Feb 2021 08:41:43 GMT Subject: RFR: JDK-8262199: issue in jli args.c [v5] In-Reply-To: References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken wrote: >> Sonar reports a finding in args.c, where a file check is done . >> Stat performs a check on file, and later fopen is called on the file . >> >> The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Replace reportAndExit This version looks good too. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2692 From mbaesken at openjdk.java.net Fri Feb 26 12:25:45 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 26 Feb 2021 12:25:45 GMT Subject: Integrated: JDK-8262199: issue in jli args.c In-Reply-To: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> References: <3VHMgFlEvxyhgrSoFFbxhAIUYf22XkF48ttDPRt4HwI=.f97da2c5-d9c0-4c81-878f-11559d490128@github.com> Message-ID: On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote: > Sonar reports a finding in args.c, where a file check is done . > Stat performs a check on file, and later fopen is called on the file . > > The coding could be slightly rewritten so that the potential issue is removed (however I do not think that it is such a big issue). This pull request has now been integrated. Changeset: d7efb4cc Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/d7efb4cc Stats: 25 lines in 1 file changed: 8 ins; 15 del; 2 mod 8262199: issue in jli args.c Reviewed-by: clanger, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2692 From akozlov at openjdk.java.net Fri Feb 26 12:26:18 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 12:26:18 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v19] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits: - Merge branch 'master' into jdk-macos - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos - Re-do safefetch.hpp - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos - stubRoutines.inline.hpp -> safefetch.hpp - Update copyrights - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline - Extract SafeFetch32/N to stubRoutines.inline.hpp - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp" This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0. - ... and 79 more: https://git.openjdk.java.net/jdk/compare/d7efb4cc...74687c0b ------------- Changes: https://git.openjdk.java.net/jdk/pull/2200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18 Stats: 2953 lines in 74 files changed: 2862 ins; 27 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From lancea at openjdk.java.net Fri Feb 26 12:26:42 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 26 Feb 2021 12:26:42 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits [v3] In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/NumericFormatException/NumberFormatException, remove default id Looks good Joe. Added myself as a reviewer to the CSR as well ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2732 From akozlov at openjdk.java.net Fri Feb 26 12:53:11 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 12:53:11 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v20] In-Reply-To: References: Message-ID: <4ipGJ8KKE0_KPuWfExCo1jo3Tg9iewQkSKuZTcntoNE=.8c1c3dcb-4db2-4e0a-b42f-6db5f78c6406@github.com> > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #10 from VladimirKempik/pull/2200 Fix build after merge with master - Fix build after merge with master ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/74687c0b..241aedee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18-19 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From vkempik at openjdk.java.net Fri Feb 26 12:55:50 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Fri, 26 Feb 2021 12:55:50 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> support macos_aarch64 in hsdis > > src/java.base/macosx/native/libjli/java_md_macosx.m line 210: > >> 208: if (preferredJVM == NULL) { >> 209: #if defined(__i386__) >> 210: preferredJVM = "client"; > > #if defined(__i386__) > preferredJVM = "client"; > Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. Hello I thought the openjdk7 supported 32-bit macos at some point in time ------------- PR: https://git.openjdk.java.net/jdk/pull/2200 From github.com+828220+forax at openjdk.java.net Fri Feb 26 13:20:47 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 26 Feb 2021 13:20:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> Message-ID: <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com> On Fri, 26 Feb 2021 13:13:19 GMT, Jim Laskey wrote: >> Stayin' alive > > Looking for some final code reviews. I still don't like the fact that the factory uses reflection but i don't see how to do better ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From jlaskey at openjdk.java.net Fri Feb 26 13:20:46 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 26 Feb 2021 13:20:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators In-Reply-To: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> References: <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com> Message-ID: On Mon, 4 Jan 2021 13:54:14 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Stayin' alive Looking for some final code reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From odrotbohm at vmware.com Fri Feb 26 13:41:48 2021 From: odrotbohm at vmware.com (Oliver Drotbohm) Date: Fri, 26 Feb 2021 13:41:48 +0000 Subject: Inconsistency in Constructor.getGenericParameterTypes() References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com> Message-ID: <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com> Previously sent to the wrong list. Sorry for the double post. Von: Oliver Drotbohm Betreff: Inconsistency in Constructor.getGenericParameterTypes() Datum: 25. Februar 2021 um 10:03:12 MEZ An: jdk-dev at openjdk.java.net Hi all, we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that? Here's a the output of a reproducer (below): static class StaticGeneric - names: value, string static class StaticGeneric - parameters: [class java.lang.Object, class java.lang.String] static class StaticGeneric - generic parameters: [T, class java.lang.String] class NonStaticGeneric - names: this$0, value, String class NonStaticGeneric - parameters: [class Sample, class java.lang.Object, class java.lang.String] class NonStaticGeneric - generic parameters: [T, class java.lang.String] class NonStaticNonGeneric - names: this$0, String class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String] class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String] Note how the constructor of the NonStaticGeneric type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types. Tested on JDK 8 to 15. Same behavior. Cheers, Ollie class Sample { public static void main(String[] args) { Constructor first = StaticGeneric.class.getDeclaredConstructors()[0]; System.out.println("static class StaticGeneric - names: " + Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("static class StaticGeneric - parameters: " + Arrays.toString(first.getParameterTypes())); System.out.println( "static class StaticGeneric - generic parameters: " + Arrays.toString(first.getGenericParameterTypes())); System.out.println(); Constructor second = NonStaticGeneric.class.getDeclaredConstructors()[0]; System.out.println("class NonStaticGeneric - names: " + Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("class NonStaticGeneric - parameters: " + Arrays.toString(second.getParameterTypes())); System.out .println( "class NonStaticGeneric - generic parameters: " + Arrays.toString(second.getGenericParameterTypes())); System.out.println(); Constructor third = NonStaticNonGeneric.class.getDeclaredConstructors()[0]; System.out.println("class NonStaticNonGeneric - names: " + Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes())); System.out .println( "class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes())); } static class StaticGeneric { StaticGeneric(T value, String string) {} } class NonStaticGeneric { NonStaticGeneric(T value, String String) {} } class NonStaticNonGeneric { NonStaticNonGeneric(String String) {} } } From vlivanov at openjdk.java.net Fri Feb 26 13:57:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 26 Feb 2021 13:57:40 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu wrote: >> Hi all, >> >> Vector API fails to work when: >> - case 1: MaxVectorSize is set to <=8, or >> - case 2: C2 is disabled >> >> The reason is that {max/preferred} VectorShape initialization fails in both cases. >> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). >> >> Vector API should not depend on C2 to run. >> It should work even there is no JIT compiler since it's a Java-level api. >> So let's fix it. >> >> Testing: >> - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove -XX:TieredStopAtLevel=3 IMO the fix should be in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`. JVM does the right job when it signals vector support is absent (by returning `-1`). `jdk.incubator.vector` implementation should take that into account and choose a preferred shape for pure Java execution mode. ------------- Changes requested by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2722 From mcimadamore at openjdk.java.net Fri Feb 26 14:30:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 26 Feb 2021 14:30:55 GMT Subject: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently Message-ID: This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout. The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances. ------------- Commit messages: - Reduce concurrency in handshake test Changes: https://git.openjdk.java.net/jdk/pull/2748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260869 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2748/head:pull/2748 PR: https://git.openjdk.java.net/jdk/pull/2748 From daniel.daugherty at oracle.com Fri Feb 26 14:37:11 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 26 Feb 2021 09:37:11 -0500 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: References: Message-ID: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> On 2/26/21 7:55 AM, Vladimir Kempik wrote: > On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: > >>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >>> >>> support macos_aarch64 in hsdis >> src/java.base/macosx/native/libjli/java_md_macosx.m line 210: >> >>> 208: if (preferredJVM == NULL) { >>> 209: #if defined(__i386__) >>> 210: preferredJVM = "client"; >> #if defined(__i386__) >> preferredJVM = "client"; >> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS. > Hello > I thought the openjdk7 supported 32-bit macos at some point in time The macOS porting project supported 32-bit macOS, but when the code was integrated into OpenJDK7 I don't believe that 32-bit macOS was supported. I could be wrong... it was quite a while ago... Dan > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/2200 From erik.joelsson at oracle.com Fri Feb 26 15:06:39 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 26 Feb 2021 07:06:39 -0800 Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9] In-Reply-To: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> References: <77712482-850c-3945-2c4e-7865544a412b@oracle.com> Message-ID: On 2021-02-26 06:37, daniel.daugherty at oracle.com wrote: > On 2/26/21 7:55 AM, Vladimir Kempik wrote: >> On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty >> wrote: >> >>>> Anton Kozlov has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? support macos_aarch64 in hsdis >>> src/java.base/macosx/native/libjli/java_md_macosx.m line 210: >>> >>>> 208:???? if (preferredJVM == NULL) { >>>> 209: #if defined(__i386__) >>>> 210:???????? preferredJVM = "client"; >>> #if defined(__i386__) >>> ???????? preferredJVM = "client"; >>> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on >>> macOS. >> Hello >> I thought the openjdk7 supported 32-bit macos at some point in time > > The macOS porting project supported 32-bit macOS, but when the code > was integrated into OpenJDK7 I don't believe that 32-bit macOS was > supported. I could be wrong... it was quite a while ago... > AFAIK, OpenJDK never supported 32bit macos, but there are certainly leftovers here and there indicating that the original source did at some point. In the build system we cleaned that up a long time ago. /Erik From jiefu at openjdk.java.net Fri Feb 26 15:39:42 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 26 Feb 2021 15:39:42 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com> On Fri, 26 Feb 2021 13:55:15 GMT, Vladimir Ivanov wrote: > IMO the fix should be in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`. > > JVM does the right job when it signals vector support is absent (by returning `-1`). > > `jdk.incubator.vector` implementation should take that into account and choose a preferred shape for pure Java execution mode. Hi @iwanowww , Thanks for your review. >From the view of C2 compiler, you are right. But the Java programmer may be confused if we got something like DoubleVector.SPECIES_PREFERRED.length() > VectorSupport.getMaxLaneCount(double.class). I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API. What do you think? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From vlivanov at openjdk.java.net Fri Feb 26 15:50:41 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 26 Feb 2021 15:50:41 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com> Message-ID: On Fri, 26 Feb 2021 15:37:08 GMT, Jie Fu wrote: > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API. It doesn't make much sense to me. `VectorSupport` is an internal API for `jdk.incubator.vector` to consume. It's `jdk.incubator.vector` job to interpret the result and adapt accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From naoto at openjdk.java.net Fri Feb 26 15:59:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 26 Feb 2021 15:59:40 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits [v3] In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/NumericFormatException/NumberFormatException, remove default id Looks good. Thanks for making the changes. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2732 From jpai at openjdk.java.net Fri Feb 26 17:08:58 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 26 Feb 2021 17:08:58 GMT Subject: RFR: 8173970: jar tool should have a way to extract to a directory Message-ID: Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752 From cgo at openjdk.java.net Fri Feb 26 17:56:03 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Fri, 26 Feb 2021 17:56:03 GMT Subject: RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java Message-ID: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java ------------- Commit messages: - Fixes coding style. Changes: https://git.openjdk.java.net/jdk/pull/2754/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2754&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262471 Stats: 13 lines in 1 file changed: 0 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2754/head:pull/2754 PR: https://git.openjdk.java.net/jdk/pull/2754 From psandoz at openjdk.java.net Fri Feb 26 17:58:41 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 26 Feb 2021 17:58:41 GMT Subject: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore wrote: > This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout. > > The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances. test/jdk/java/foreign/TestHandshake.java line 60: > 58: > 59: static final int NUM_ACCESSORS = Math.max(10, Runtime.getRuntime().availableProcessors()); > 60: `min` rather than `max` so as to clamp at a maximum of 10 accessors? ------------- PR: https://git.openjdk.java.net/jdk/pull/2748 From akozlov at openjdk.java.net Fri Feb 26 19:17:12 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 26 Feb 2021 19:17:12 GMT Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21] In-Reply-To: References: Message-ID: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos - Minor fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/241aedee..663cb4a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19-20 Stats: 85 lines in 5 files changed: 0 ins; 80 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200 From lance.andersen at oracle.com Fri Feb 26 19:47:32 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 26 Feb 2021 19:47:32 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: Message-ID: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> Hi Jaikiran, Thank you for the proposed patch. Assuming there is consensus to add support for this enhancement, I think we need to discuss what is the correct option. The jar tool borrows -C from tar for creating/updating a jar and the -C option is also a valid option when extracting files from a tar file. Perhaps keeping symmetry with tar and extend support for -C when extracting a jar file would be a better way forward. Let?s give time for additional input. I believe this would also warrant a CSR to be created as well as updates to the jar man page. Best Lance p.s. I think it would be useful in the future to start the discussion on core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature request. On Feb 26, 2021, at 12:08 PM, Jaikiran Pai > wrote: Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970? The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified. As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR. The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated). The commit also includes a jtreg testcase which verifies the usage of this new option. ------------- Commit messages: - 8173970: jar tool should have a way to extract to a directory Changes: https://git.openjdk.java.net/jdk/pull/2752/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2752.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From igraves at openjdk.java.net Fri Feb 26 20:15:19 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 26 Feb 2021 20:15:19 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5] In-Reply-To: References: Message-ID: > Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Test refactoring. Adding implNote to modified methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2596/files - new: https://git.openjdk.java.net/jdk/pull/2596/files/ebdd0f85..8109e158 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=03-04 Stats: 185 lines in 2 files changed: 12 ins; 142 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596 From igraves at openjdk.java.net Fri Feb 26 20:19:51 2021 From: igraves at openjdk.java.net (Ian Graves) Date: Fri, 26 Feb 2021 20:19:51 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4] In-Reply-To: References: <0Q1-b9nmt14hoihSeDUReR8QUMvB8_6VOxg1edY6p_Y=.f3ee334f-fa4a-4eb9-b7b2-acf88022567f@github.com> Message-ID: On Wed, 24 Feb 2021 01:58:48 GMT, Stuart Marks wrote: >>> Is there any behavior change here that merits a CSR review? >> >> Yes. See my comments in the bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-6323374?focusedCommentId=14296330&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14296330 >> >> There is not only the issue of the identity of the object returned, but the change is also observable in the serialized form. Most people would consider the change (less nesting) to be an improvement, but the change is observable, and as we know any observable behavior can become depended upon by applications. > > Code changes all look good. I'm thinking that we should add `@implNote` clauses to all the docs of the affected methods, saying something like "This method may return its argument if it is already unmodifiable." Usually it's reasonable to leave these kinds of behaviors unspecified (and we do so elsewhere) but since this is a change in long-standing behavior, it seems reasonable to highlight it explicitly. I don't think we want to specify it though, because of the issue with ImmutableCollections (as discussed previously) and possible future tuning of behavior regarding the various Set and Map subinterfaces. (For example, C.unmodifiableSet(arg) could return arg if it's an UnmodifiableNavigableSet.) > > The test seems to have a lot of uncomfortable dependencies, both explicit and implicit, on the various ImmutableCollection and UnmodifiableX implementation classes. Would it be sufficient to test various instances for reference equality and inequality instead? For example, something like > > var list0 = List.of(); > var list1 = Collections.unmodifiableList(list0); > var list2 = Collections.unmodifiableList(list1); > assertNotSame(list0, list1); > assertSame(list1, list2); > > This would avoid having to write test cases that cover various internal classes. The ImmutableCollections classes have been reorganized in the past, and while we don't have any plans to do so again at the moment, there is always the possibility of it happening again. > > One could write out all the different cases "by hand" but there are rather a lot of them. It might be fruitful to extract the "wrap once, wrap again, assertNotSame, assertSame" logic into a generic test and drive it somehow with a data provider that provides the base instance and a wrapper function. Per @stuart-marks I rewrote the tests using some of his suggestions, which substantially reduced dependencies and test size. ------------- PR: https://git.openjdk.java.net/jdk/pull/2596 From iris at openjdk.java.net Fri Feb 26 21:13:41 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 26 Feb 2021 21:13:41 GMT Subject: RFR: 8261670: Add javadoc for the XML processing limits [v3] In-Reply-To: References: Message-ID: <1sD1TgPcpcLhawvXRompkO6dR01FVVJjv0kkFOF6sss=.42ec059e-2acb-423d-b32b-9d2faa97faa4@github.com> On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/NumericFormatException/NumberFormatException, remove default id Looks good. I'm glad to see useful information from the outdated guides/tutorial being integrated into this documentation. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2732 From joe.darcy at oracle.com Fri Feb 26 21:38:48 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 26 Feb 2021 13:38:48 -0800 Subject: Inconsistency in Constructor.getGenericParameterTypes() In-Reply-To: <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com> References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com> <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com> Message-ID: Hello Oliver, This is long-standing if surprising and under-documented behavior. The getGenericFoo methods, when generic type information is present, give a source-level view of the element. At a source level, the implicit outer this parameter is not present and thus omitted by constructor.getGenericParameterTypes for the constructor in question. HTH, -Joe On 2/26/2021 5:41 AM, Oliver Drotbohm wrote: > Previously sent to the wrong list. Sorry for the double post. > > Von: Oliver Drotbohm > Betreff: Inconsistency in Constructor.getGenericParameterTypes() > Datum: 25. Februar 2021 um 10:03:12 MEZ > An: jdk-dev at openjdk.java.net > > Hi all, > > we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that? > > Here's a the output of a reproducer (below): > > static class StaticGeneric - names: value, string > static class StaticGeneric - parameters: [class java.lang.Object, class java.lang.String] > static class StaticGeneric - generic parameters: [T, class java.lang.String] > > class NonStaticGeneric - names: this$0, value, String > class NonStaticGeneric - parameters: [class Sample, class java.lang.Object, class java.lang.String] > class NonStaticGeneric - generic parameters: [T, class java.lang.String] > > class NonStaticNonGeneric - names: this$0, String > class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String] > class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String] > > Note how the constructor of the NonStaticGeneric type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types. > > Tested on JDK 8 to 15. Same behavior. > > Cheers, > Ollie > > > class Sample { > > public static void main(String[] args) { > > Constructor first = StaticGeneric.class.getDeclaredConstructors()[0]; > > System.out.println("static class StaticGeneric - names: " > + Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); > System.out.println("static class StaticGeneric - parameters: " + Arrays.toString(first.getParameterTypes())); > System.out.println( > "static class StaticGeneric - generic parameters: " + Arrays.toString(first.getGenericParameterTypes())); > > System.out.println(); > > Constructor second = NonStaticGeneric.class.getDeclaredConstructors()[0]; > System.out.println("class NonStaticGeneric - names: " > + Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); > System.out.println("class NonStaticGeneric - parameters: " + Arrays.toString(second.getParameterTypes())); > System.out > .println( > "class NonStaticGeneric - generic parameters: " + Arrays.toString(second.getGenericParameterTypes())); > > System.out.println(); > > Constructor third = NonStaticNonGeneric.class.getDeclaredConstructors()[0]; > System.out.println("class NonStaticNonGeneric - names: " > + Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); > System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes())); > System.out > .println( > "class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes())); > } > > static class StaticGeneric { > StaticGeneric(T value, String string) {} > } > > class NonStaticGeneric { > NonStaticGeneric(T value, String String) {} > } > > class NonStaticNonGeneric { > NonStaticNonGeneric(String String) {} > } > } > From smarks at openjdk.java.net Fri Feb 26 21:39:40 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 26 Feb 2021 21:39:40 GMT Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5] In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves wrote: >> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Test refactoring. Adding implNote to modified methods The `@implNote` additions are good, and the test rewrite looks good too. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2596 From rriggs at openjdk.java.net Fri Feb 26 21:53:46 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 26 Feb 2021 21:53:46 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 16:47:59 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > Jim Laskey 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 8248862 > - Adjust ThreadLocalRandom javadoc inheritence > - L32X64StarStarRandom -> L32X64MixRandom > - Various corrects > - Revised javadoc per CSR reviews > - Remove tabs from random/package-info.java > - Correct copyright notice. > - Merge branch 'master' into 8248862 > - Update tests for RandomGeneratorFactory.all() > - Merge branch 'master' into 8248862 > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279 src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 232: > 230: Provider provider = fm.get(name); > 231: if (!isSubclass(category, provider)) { > 232: throw new IllegalArgumentException(name + " is an unknown random number generator"); The message is a bit vague. How about: "The random number generator does not support the category" src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 240: > 238: * Returns a {@link RandomGenerator} that utilizes the {@code name} > 239: * algorithm. > 240: * In javadoc, this seems like is should read as: "utilizes the named algorithm". The use of the parameter name is unnecessary in this case because it is obvious and readability suffers as is. src/java.base/share/classes/java/util/random/RandomGenerator.java line 1313: > 1311: * furthermore can easily jump to an arbitrarily specified distant > 1312: * point in the state cycle. > 1313: * The similarity of the first sentence of each of the Jumpable, Leapable, and arbitrarlyJumpable interface is so similar as to obscure the differences. You have to read 25 words in to be able to find the description that makes them different. The italics help but should include the whole of the phrase that distinguishes them. Alternatively, move the phrase to the beginning of the sentence or drop the redundant phrasing. "provide a common protocol of objects that generate pseudorandom sequences of numbers of Boolean values", etc. src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 55: > 53: * > 54: * A specific {@link RandomGeneratorFactory} can be located by using the > 55: * {@link RandomGenerator#factoryOf(String)} method, where the argument string Broken link: the method is in this class. should be just "#factoryOf". src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 600: > 598: try { > 599: ensureConstructors(); > 600: return ctorBytes.newInstance((Object)seed); IntelliJ warns that the cast to (Object) is redundant. src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 29: > 27: > 28: import java.lang.reflect.Constructor; > 29: import java.lang.reflect.Method; Used import. ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From rriggs at openjdk.java.net Fri Feb 26 21:53:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 26 Feb 2021 21:53:47 GMT Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3] In-Reply-To: References: Message-ID: <0VaZHVlAPVPZOyMk1UK1j3ujLDQEwYeYx3dG_cwBHfA=.9d457d8b-4625-4943-ae0f-935d2462f31d@github.com> On Wed, 25 Nov 2020 16:22:32 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 106: >> >>> 104: * Map of provider classes. >>> 105: */ >>> 106: private static volatile Map> factoryMap; >> >> should be FACTORY_MAP given that it's a static field > > will fall out of using class holder idiom IntelliJ warns that this volatile field is unused. It has been replaced by the method getFactoryMap(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1292 From odrotbohm at vmware.com Fri Feb 26 22:20:54 2021 From: odrotbohm at vmware.com (Oliver Drotbohm) Date: Fri, 26 Feb 2021 22:20:54 +0000 Subject: Inconsistency in Constructor.getGenericParameterTypes() In-Reply-To: References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com> <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com> Message-ID: Hi Joe, thanks for the explanation. We switched to rather iterating over ?.getParameters() and take it from there. Do you think it makes sense to leave a note about this in the Javadoc? Cheers, Ollie > Am 26.02.2021 um 22:38 schrieb Joe Darcy : > > Hello Oliver, > > This is long-standing if surprising and under-documented behavior. > > The getGenericFoo methods, when generic type information is present, give a source-level view of the element. At a source level, the implicit outer this parameter is not present and thus omitted by constructor.getGenericParameterTypes for the constructor in question. > > HTH, > > -Joe > > On 2/26/2021 5:41 AM, Oliver Drotbohm wrote: >> Previously sent to the wrong list. Sorry for the double post. >> >> Von: Oliver Drotbohm >> Betreff: Inconsistency in Constructor.getGenericParameterTypes() >> Datum: 25. Februar 2021 um 10:03:12 MEZ >> An: jdk-dev at openjdk.java.net >> >> Hi all, >> >> we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that? >> >> Here's a the output of a reproducer (below): >> >> static class StaticGeneric - names: value, string >> static class StaticGeneric - parameters: [class java.lang.Object, class java.lang.String] >> static class StaticGeneric - generic parameters: [T, class java.lang.String] >> >> class NonStaticGeneric - names: this$0, value, String >> class NonStaticGeneric - parameters: [class Sample, class java.lang.Object, class java.lang.String] >> class NonStaticGeneric - generic parameters: [T, class java.lang.String] >> >> class NonStaticNonGeneric - names: this$0, String >> class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String] >> class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String] >> >> Note how the constructor of the NonStaticGeneric type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types. >> >> Tested on JDK 8 to 15. Same behavior. >> >> Cheers, >> Ollie >> >> >> class Sample { >> >> public static void main(String[] args) { >> >> Constructor first = StaticGeneric.class.getDeclaredConstructors()[0]; >> >> System.out.println("static class StaticGeneric - names: " >> + Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); >> System.out.println("static class StaticGeneric - parameters: " + Arrays.toString(first.getParameterTypes())); >> System.out.println( >> "static class StaticGeneric - generic parameters: " + Arrays.toString(first.getGenericParameterTypes())); >> >> System.out.println(); >> >> Constructor second = NonStaticGeneric.class.getDeclaredConstructors()[0]; >> System.out.println("class NonStaticGeneric - names: " >> + Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); >> System.out.println("class NonStaticGeneric - parameters: " + Arrays.toString(second.getParameterTypes())); >> System.out >> .println( >> "class NonStaticGeneric - generic parameters: " + Arrays.toString(second.getGenericParameterTypes())); >> >> System.out.println(); >> >> Constructor third = NonStaticNonGeneric.class.getDeclaredConstructors()[0]; >> System.out.println("class NonStaticNonGeneric - names: " >> + Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); >> System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes())); >> System.out >> .println( >> "class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes())); >> } >> >> static class StaticGeneric { >> StaticGeneric(T value, String string) {} >> } >> >> class NonStaticGeneric { >> NonStaticGeneric(T value, String String) {} >> } >> >> class NonStaticNonGeneric { >> NonStaticNonGeneric(String String) {} >> } >> } >> From jai.forums2013 at gmail.com Sat Feb 27 01:59:14 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 27 Feb 2021 07:29:14 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> Message-ID: <6fe7241d-8594-07ce-80ec-0006062c268e@gmail.com> Hello Lance, On 27/02/21 1:17 am, Lance Andersen wrote: > > > p.s. I think it would be useful in the future to start the discussion > on core-libs-dev prior to creating a PR (or leave it as a draft PR) > for a feature request. Thank you for that input, I'll keep that in mind for any similar work in future. -Jaikiran From jai.forums2013 at gmail.com Sat Feb 27 02:03:43 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 27 Feb 2021 07:33:43 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> Message-ID: <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com> On 27/02/21 1:17 am, Lance Andersen wrote: > > I believe this would also warrant a CSR to be created as well as > updates to the jar man page. I haven't created a CSR before, so I will need some guidance on that part. Is it usually created after all the implementation details have been decided upon or should it be created now? -Jaikiran From jiefu at openjdk.java.net Sat Feb 27 03:23:12 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 27 Feb 2021 03:23:12 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5] In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com> > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 Jie Fu 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 seven additional commits since the last revision: - Fix in jdk/incubator/vector/VectorShape.java - Merge branch 'master' into JDK-8262096 - Revert changes - Remove -XX:TieredStopAtLevel=3 - Update the jtreg test - The numerator should be 8 (byte) - 8262096: Vector API fails to work due to VectorShape initialization exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/bbe6150c..b67b232d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03-04 Stats: 7047 lines in 380 files changed: 3707 ins; 1675 del; 1665 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Sat Feb 27 03:26:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 27 Feb 2021 03:26:41 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <4nqS6MYId9oNEztpqjrqKivgX7j0D_9hfqSdOXcbKrA=.4ecc4948-8924-4308-b2a3-c98491de3f8e@github.com> Message-ID: On Fri, 26 Feb 2021 15:48:18 GMT, Vladimir Ivanov wrote: > > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= VectorSupport.getMaxLaneCount(double.class) for Java programmers since the VectorSupport_GetMaxLaneCount is used to implement a Java API. > > It doesn't make much sense to me. `VectorSupport` is an internal API for `jdk.incubator.vector` to consume. > It's `jdk.incubator.vector` job to interpret the result and adapt accordingly. Okay, I'm fine to fix it in jdk/incubator/vector/VectorShape.java if we don't keep something like that. For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization. Testing: - jdk/incubator/vector with MaxVectorSize=default/8/4 on Linux/x64 - jdk/incubator/vector without C2 on Linux/x64 Any comments? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From alanb at openjdk.java.net Sat Feb 27 08:06:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 27 Feb 2021 08:06:39 GMT Subject: RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com> References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com> Message-ID: On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes wrote: > Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2754 From Alan.Bateman at oracle.com Sat Feb 27 08:53:23 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Feb 2021 08:53:23 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> Message-ID: On 26/02/2021 19:47, Lance Andersen wrote: > Hi Jaikiran, > > Thank you for the proposed patch. > > Assuming there is consensus to add support for this enhancement, I think we need to discuss what is the correct option. > > The jar tool borrows -C from tar for creating/updating a jar and the -C option is also a valid option when extracting files from a tar file. > > Perhaps keeping symmetry with tar and extend support for -C when extracting a jar file would be a better way forward. Let?s give time for additional input. > > I believe this would also warrant a CSR to be created as well as updates to the jar man page. > > Best > Lance > > p.s. I think it would be useful in the future to start the discussion on core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature request. I created JDK-8173970 a few years ago so happy it it getting some attention. Yes, the option name will need to be agreed. It would be useful to enumerate the options that the other tools are using to specify the location where to extract. If you see JBS issues mentioning tar -C not supporting chdir when extracting then it might be Solaris tar, which isn't the same as GNU tar which has different options. It might be better to look at more main stream tools, like unzip although jar -d is already taken. It would be nice if there were some consistency with other tools in the JDK that doing extracting (The jmod and jimage extract commands use use --dir for example). There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools. Yes, a CSR will be needed. -Alan From vlivanov at openjdk.java.net Sat Feb 27 11:02:54 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Sat, 27 Feb 2021 11:02:54 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5] In-Reply-To: <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com> Message-ID: On Sat, 27 Feb 2021 03:23:12 GMT, Jie Fu wrote: >> Hi all, >> >> Vector API fails to work when: >> - case 1: MaxVectorSize is set to <=8, or >> - case 2: C2 is disabled >> >> The reason is that {max/preferred} VectorShape initialization fails in both cases. >> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). >> >> Vector API should not depend on C2 to run. >> It should work even there is no JIT compiler since it's a Java-level api. >> So let's fix it. >> >> Testing: >> - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 > > Jie Fu 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 seven additional commits since the last revision: > > - Fix in jdk/incubator/vector/VectorShape.java > - Merge branch 'master' into JDK-8262096 > - Revert changes > - Remove -XX:TieredStopAtLevel=3 > - Update the jtreg test > - The numerator should be 8 (byte) > - 8262096: Vector API fails to work due to VectorShape initialization exception > For the updated fix, the {max/preferred} shape will be initialized as shape-64-bit if hotspot doesn't support vectorization. Sounds reasonable. test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42: > 40: * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector > 41: * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest > 42: * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest `-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Sat Feb 27 11:18:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 27 Feb 2021 11:18:00 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v6] In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> Message-ID: > Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add requires vm.compiler2.enabled ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/b67b232d..79402411 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722 From jiefu at openjdk.java.net Sat Feb 27 11:18:03 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 27 Feb 2021 11:18:03 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com> Message-ID: On Sat, 27 Feb 2021 10:58:16 GMT, Vladimir Ivanov wrote: >> Jie Fu 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 seven additional commits since the last revision: >> >> - Fix in jdk/incubator/vector/VectorShape.java >> - Merge branch 'master' into JDK-8262096 >> - Revert changes >> - Remove -XX:TieredStopAtLevel=3 >> - Update the jtreg test >> - The numerator should be 8 (byte) >> - 8262096: Vector API fails to work due to VectorShape initialization exception > > test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42: > >> 40: * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector >> 41: * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest >> 42: * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest > > `-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`. `@requires vm.compiler2.enabled` had been added. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722 From lance.andersen at oracle.com Sat Feb 27 12:08:54 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 27 Feb 2021 12:08:54 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com> Message-ID: <52B68EB8-7904-45FF-817C-CAB8589D6818@oracle.com> HI Jaikiran, I am more than happy to work with you through the CSR process Lets get the discussion going regarding possible option names on core-libs-dev and then we can move forward :-) Have a great weekend On Feb 26, 2021, at 9:03 PM, Jaikiran Pai > wrote: On 27/02/21 1:17 am, Lance Andersen wrote: I believe this would also warrant a CSR to be created as well as updates to the jar man page. I haven't created a CSR before, so I will need some guidance on that part. Is it usually created after all the implementation details have been decided upon or should it be created now? -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From attila at openjdk.java.net Sat Feb 27 20:01:10 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sat, 27 Feb 2021 20:01:10 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v3] In-Reply-To: References: Message-ID: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2617/files - new: https://git.openjdk.java.net/jdk/pull/2617/files/3afec32b..f5922c48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=01-02 Stats: 25 lines in 2 files changed: 11 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2617/head:pull/2617 PR: https://git.openjdk.java.net/jdk/pull/2617 From attila at openjdk.java.net Sat Feb 27 20:12:39 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sat, 27 Feb 2021 20:12:39 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 15:34:30 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 79: > >> 77: >> 78: public static void main(String[] args) { >> 79: for (int count = 0; count < MAX_ITERATIONS; ++count) { > > Here and later: use postfix `count++`, regular style? Old habits die hard; I think I started doing this about 30 years ago when writing C code against a compiler on Atari ST that emitted more efficient MC68000 code for `++i` than for `i++`. I guess it's time to unlearn this :-) Of course, if you wanted to get the fastest code, you would've counted _decrementing to zero_ to let the compiler use the DBRA (decrement and branch) instruction. It's funny how I _don't_ miss those days. ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From attila at openjdk.java.net Sat Feb 27 20:21:40 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sat, 27 Feb 2021 20:21:40 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Thu, 25 Feb 2021 15:34:10 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 28: > >> 26: * @bug 8198540 >> 27: * @summary Test TypeConverterFactory is not leaking method handles >> 28: * @run main/othervm -Xmx4M TypeConverterFactoryMemoryLeakTest > > I think `-Xmx4m` is risking it on some platforms that cannot go that low heap. Maybe do 128M, and bulk up the test allocations, so that GC definitely triggers? I removed the `-Xmx` option altogether on @plevart's suggestion to invoke `System.gc` explicitly instead. I added multiple @run directives, with all current GCs. (BTW, do I need to add `@requires vm.gc.Shenandoah` to the tests if I include Shenandoah?) It's funny how ZGC and Shenandoah need 1 iteration less than all other GCs. If a test needs 12 iterations with most GCs, ZGC and Shenandoah need 11. If a test needs 2 iterations with others, these two will get it done in 1. ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From attila at openjdk.java.net Sat Feb 27 20:31:39 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sat, 27 Feb 2021 20:31:39 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 08:03:26 GMT, Peter Levart wrote: >> The good test would be trying with all current GCs (Serial, Parallel, G1, Shenandoah, ZGC): >> >> make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC >> >> Also, make sure that GH actions are able to run this test. You probably need to enable the workflow here -- https://github.com/szegedi/jdk/actions -- and then trigger the workflow manually on your branch (or push another commit). Then "Checks" tab would show the results. > >> > I would like 1st to understand why the MH created in the TestLinker.convertToType is actually GCed at all. >> >> The whole original issue was about allowing these objects to be GCd smile. >> Short story: because all data is scoped to objects created within `makeOne` method. > > Right, below description helped me understand the "chain of domination - i.e. hard references that keep the BiClassValueRoot (extends ClassValue) reachable". That doesn't explain fully why converters are not GC-ed as soon as the associated BiClassValueRoot is eligible for GC. The secret lies in the implementation of ClassValue... > >> >> Longer story: It is GC'd because its reachability is dominated by the `DynamicLinker` object created on [line 96](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java#L96). It and everything it dominates (`LinkerServicesImpl` object holding the `TypeConverterFactory` object holding the `BiClassValue` objects holding the method handles) become garbage as soon as the method exits. > > That is not entirely true. What becomes garbage is the objects leading to the BiClassValueRoot (extends ClassValue) instance including the BiClassValueRoot instance. But it is not the ClassValue instance that keeps the associated T value(s) reachable. The associated values are strongly reachable from the associated Class instances. The Class class contains an instance field of type ClassValueMap which is responsible for keeping the associated values. This answers my question why the associated converter is GCed only after 12 new converters are created for the same source/target type pair. It is not because creating new converters would cause memory pressure and consequently trigger GC (I tried adding explicit System.gc() calls and they did not expedite the GCing of the converter). It is because ClassValue logic expunges associated T values from Class.ClassValueMap only at times when it has to re-arrange the map's internal structures and that eventually happens on new inser tions for the same Class instance and different ClassValue instance. > > That doesn't mean type converter caching is flawed in any way. It just means that some converters will be retained even though they are practically not "reachable" any more through the mechanism of caching. That doesn't mean that any ClassLoader leaks are possible either. > >> This works because of the pains I took in `BiClassValue` to ensure we don't leak any of the infrastructural objects through implicit `this$0` outer-class references into the `ClassValue`s. That allows the `ClassValue` objects to be GCd and removed from the classes' class-value mapping. This ordinarily doesn't happen as most `ClassValue` objects are bound to static fields, but in `TypeConverterFactory` the `BiClassValue` instances are specific to the `TypeConverterFactory` instance, so they are expected to be reclaimable by GC if the converter factory itself goes away. >> >> > And after that, why it is not GCed before 12 invocations to makeOne() are made. >> >> Because GC is at liberty to delay recognizing an object is phantom reachable? I don't think we need to read too much into this? Correct me if I don't see something. > > As described above, GC has nothing to do with this "delay". It is caused by the way ClassValue keeps associated values reachable from the associated Class instances (that appear semantically as keys, but in fact it's the other way arround - ClassValue instances are weakly reachable keys and Class instances hold the maps). > >> >> > What would be more interesting to test is to create a converter between a type loaded by a custom (child) ClassLoader and a system type. After that, release all hard references to the custom ClassLoader and see if the converter gets GC-ed as a result. WDYT? >> >> That does sound like [TypeConverterFactoryRetentionTests.testSystemLoaderToOtherLoader](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java#L118) True, it tests whether the _class loader_ itself gets released, not the converter, but the loader would hardly get released while there's a converter with the class from that loader bound in the parameter signature of its method handle, wouldn't it? > > Yes, that test is exactly what I was thinking about. > >> >> Regardless, if you think there's a valid use case for this additional test, we can discuss it. I'd rather scope this issue to fixing the flakiness of the tests, so they don't cause trouble with builds and can be backported/added to ongoing backports. >> >> Thanks for taking time to look into this! > > I think the tests cover what needs to be covered. I would just iterate the same test over all GC implementations (as Aleksey already suggested) and instead of minimizing the heap size (which could cause problems in some GC implementations as they evolve), insert explicit System.gc() calls in the loops to trigger GC cycles that also process Reference(s). I tried that with all current CG implementations (SerialGC, G1GC, ParallelGC, ZGC and ShenandoahGC) and they all respect System.gc() calls. Even though I increased heap size to 128M, the 1st associated converter always got GCed after 12 new converters were created for the same source/target class pair. > ? It is because ClassValue logic expunges associated T values from Class.ClassValueMap only at times when it has to re-arrange the map's internal structures and that eventually happens on new insertions for the same Class instance and different ClassValue instance. When I diagnosed the original issue by taking the heap dump and tracking the undesirable reachability from GC roots, I fixed it, then wrote the tests, and could see that before my changes the tests failed, and after the changes they passed, so stuff is no longer retained by class values ??good enough for me, done! You on the other hand, need to understand _why 12 iterations_. I sincerely admire how you're methodically going after the details and need to understand the whole picture. > I think the tests cover what needs to be covered. I would just iterate the same test over all GC implementations (as Aleksey already suggested) and instead of minimizing the heap size (which could cause problems in some GC implementations as they evolve), insert explicit System.gc() calls in the loops to trigger GC cycles that also process Reference(s). I tried that with all current CG implementations (SerialGC, G1GC, ParallelGC, ZGC and ShenandoahGC) and they all respect System.gc() calls. Even though I increased heap size to 128M, the 1st associated converter always got GCed after 12 new converters were created for the same source/target class pair. Done: added `@run` directives for all GCs, and in fact removed the `-Xmx` as it is not relevant; memory leak test succeeds after 12 iterations (11 with Shenandoah and ZGC) and the retention tests succeed after 2 iterations (or 1 with with Shenandoah and ZGC). ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From jai.forums2013 at gmail.com Sun Feb 28 04:19:37 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 28 Feb 2021 09:49:37 +0530 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> Message-ID: <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> Hello Alan, On 27/02/21 2:23 pm, Alan Bateman wrote: > > Yes, the option name will need to be agreed. It would be useful to > enumerate the options that the other tools are using to specify the > location where to extract. If you see JBS issues mentioning tar -C not > supporting chdir when extracting then it might be Solaris tar, which > isn't the same as GNU tar which has different options. It might be > better to look at more main stream tools, like unzip although jar -d > is already taken. It would be nice if there were some consistency with > other tools in the JDK that doing extracting (The jmod and jimage > extract commands use use --dir for example). I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup that I had access to. -------------- tar on MacOS: -------------- tar --version bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6 The version of this tool has: -C directory, --cd directory, --directory directory ???????????? In c and r mode, this changes the directory before adding the following files. ???????????? In x mode, change directories after opening the archive but before extracting ???????????? entries from the archive. A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ -------------- tar on CentOS: -------------- tar --version tar (GNU tar) 1.26 This version of the tool has: Common options: ?????? -C, --directory=DIR ????????????? change to directory DIR Although the wording isn't clear that, when used with -x, it extracts to the directory specified in -C, it does indeed behave that way. Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ ------------------------------- unzip on both MacOS and CentOS: ------------------------------- unzip -v UnZip 6.00 of 20 April 2009, by Info-ZIP.? Maintained by C. Spieler. This version of the tool has: [-d exdir] ????????????? An optional directory to which to extract files.? By default, all files and sub- ????????????? directories are recreated in the current directory; the -d option allows extrac- ????????????? tion in an arbitrary directory (always assuming one has permission to? write? to ????????????? the? directory).? This option need not appear at the end of the command line; it ????????????? is also accepted before the zipfile specification (with? the? normal? options), ????????????? immediately? after? the zipfile specification, or between the file(s) and the -x ????????????? option.? The option and directory may be concatenated without? any? white? space ????????????? between? them,? but? note? that? this may cause normal shell behavior to be sup- ????????????? pressed.? In particular, ``-d ~'' (tilde) is expanded by Unix C shells into? the ????????????? name of the user's home directory, but ``-d~'' is treated as a literal subdirec- ????????????? tory ``~'' of the current directory. unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current directory to /tmp/bar/ --------------- jimage and jmod --------------- The jimage and jmod as you note use the --dir option for extracting to that specified directory. Those were the tools I looked at. I think using the -d option with -x for the jar command is ruled out since it already is used for a different purpose, although for a different "main" operation of the jar command. As for using --dir for this new feature, I don't think it alone will be enough. Specifically, I couldn't find a "short form" option for the --dir option in the jimage or jmod commands. For the jar extract feature that we are discussing here, I think having a short form option (in addition to the longer form) is necessary to have it match the usage expectations of similar other options that the jar command exposes. So even if we do choose --dir as the long form option, we would still need a short form for it and since -d is already taken for something else, we would still need to come up with a different one. The short form of this option could be -C (see below). I think reusing the -C option, for this new feature, perhaps is a good thing. The -C is currently used by the update and create "main" operation of the jar command and the man page for this option states: -C dir ????????????? When creating (c) or updating (u) a JAR file, this option temporarily changes ????????????? the directory while processing files specified by the file operands. Its ????????????? operation is intended to be similar to the -C option of the UNIX tar utility.For ????????????? example, the following command changes to the classes directory and adds the ????????????? Bar.class file from that directory to my.jar: ????????????? jar uf my.jar -C classes Bar.class .... Using the -C option would indeed align it with the tar command. For the "long form" of this option, the tar command (both on MacOS and CentOS) uses --directory. For this jar extract feature though, we could perhaps just use --dir to have it align with the jimage and the jmod tools. So I think the combination of -C (short form) and --dir (long form) would perhaps be suitable for this feature. > > There are other discussion points around the behavior when the target > directory exists or does not exist, to ensure there is some > consistency with main stream tools. I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify: unzip foo.zip -d /tmp/blah/ and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it. However, unzip foo.zip -d /tmp/blah/hello/ and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories. Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like: jimage extract --dir /tmp/blah/foo/bar/ jdkmodules will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image. From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands. One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran From shade at openjdk.java.net Sun Feb 28 07:23:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 28 Feb 2021 07:23:45 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v3] In-Reply-To: References: Message-ID: On Sat, 27 Feb 2021 20:01:10 GMT, Attila Szegedi wrote: >> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" > > Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC Changes requested by shade (Reviewer). test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 32: > 30: * @run main/othervm -XX:+UseParallelGC TypeConverterFactoryMemoryLeakTest > 31: * @run main/othervm -XX:+UseZGC TypeConverterFactoryMemoryLeakTest > 32: * @run main/othervm -XX:+UseShenandoahGC TypeConverterFactoryMemoryLeakTest Ah, here is a test trivia. Some configurations do not have either ZGC or Shenandoah. So you need to check GC availabilty before adding `@run`. For consistency, checking every GC availability is even better. Usually done by splitting the `@test` blocks, and adding `@requires` tags: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java#L37-L107 ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From shade at openjdk.java.net Sun Feb 28 07:23:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 28 Feb 2021 07:23:45 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2] In-Reply-To: References: Message-ID: On Sat, 27 Feb 2021 20:10:15 GMT, Attila Szegedi wrote: >> test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 79: >> >>> 77: >>> 78: public static void main(String[] args) { >>> 79: for (int count = 0; count < MAX_ITERATIONS; ++count) { >> >> Here and later: use postfix `count++`, regular style? > > Old habits die hard; I think I started doing this about 30 years ago when writing C code against a compiler on Atari ST that emitted more efficient MC68000 code for `++i` than for `i++`. I guess it's time to unlearn this :-) Of course, if you wanted to get the fastest code, you would've counted _decrementing to zero_ to let the compiler use the DBRA (decrement and branch) instruction. > > It's funny how I _don't_ miss those days. Good! ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From attila at openjdk.java.net Sun Feb 28 10:28:56 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 28 Feb 2021 10:28:56 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v4] In-Reply-To: References: Message-ID: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" Attila Szegedi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC ------------- Changes: https://git.openjdk.java.net/jdk/pull/2617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=03 Stats: 94 lines in 3 files changed: 71 ins; 10 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2617/head:pull/2617 PR: https://git.openjdk.java.net/jdk/pull/2617 From attila at openjdk.java.net Sun Feb 28 10:28:57 2021 From: attila at openjdk.java.net (Attila Szegedi) Date: Sun, 28 Feb 2021 10:28:57 GMT Subject: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v3] In-Reply-To: References: Message-ID: On Sun, 28 Feb 2021 07:20:19 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 61: > >> 59: // With explicit GC calls succeeds in 11-12 iterations depending on GC used. >> 60: // 1000 should be a safe upper limit after which we can consider it failed. >> 61: private static final int MAX_ITERATIONS = 1000; > > Ah, here is a test trivia. Some configurations do not have either ZGC or Shenandoah. So you need to check GC availabilty before adding `@run`. For consistency, checking every GC availability is even better. Usually done by splitting the `@test` blocks, and adding `@requires` tags: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java#L37-L107 Thanks, that's an excellent suggestion! Implemented it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/2617 From lance.andersen at oracle.com Sun Feb 28 12:08:16 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 28 Feb 2021 12:08:16 +0000 Subject: RFR: 8173970: jar tool should have a way to extract to a directory In-Reply-To: <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> References: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com> <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com> Message-ID: Hi Jaikiran, Thank you for this. I went through this myself yesterday in addition to what you have below here are a few more: 7zip: -o Info-zip: -d (MacOS version of zip) Bandzip: -o:{dir} jpackage: -d ?dest jlink ?output Thinking about this some more, I might suggest supporting -C ?dir ?directory Best Lance On Feb 27, 2021, at 11:19 PM, Jaikiran Pai > wrote: Hello Alan, On 27/02/21 2:23 pm, Alan Bateman wrote: Yes, the option name will need to be agreed. It would be useful to enumerate the options that the other tools are using to specify the location where to extract. If you see JBS issues mentioning tar -C not supporting chdir when extracting then it might be Solaris tar, which isn't the same as GNU tar which has different options. It might be better to look at more main stream tools, like unzip although jar -d is already taken. It would be nice if there were some consistency with other tools in the JDK that doing extracting (The jmod and jimage extract commands use use --dir for example). I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup that I had access to. -------------- tar on MacOS: -------------- tar --version bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6 The version of this tool has: -C directory, --cd directory, --directory directory In c and r mode, this changes the directory before adding the following files. In x mode, change directories after opening the archive but before extracting entries from the archive. A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ -------------- tar on CentOS: -------------- tar --version tar (GNU tar) 1.26 This version of the tool has: Common options: -C, --directory=DIR change to directory DIR Although the wording isn't clear that, when used with -x, it extracts to the directory specified in -C, it does indeed behave that way. Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/ ------------------------------- unzip on both MacOS and CentOS: ------------------------------- unzip -v UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. This version of the tool has: [-d exdir] An optional directory to which to extract files. By default, all files and sub- directories are recreated in the current directory; the -d option allows extrac- tion in an arbitrary directory (always assuming one has permission to write to the directory). This option need not appear at the end of the command line; it is also accepted before the zipfile specification (with the normal options), immediately after the zipfile specification, or between the file(s) and the -x option. The option and directory may be concatenated without any white space between them, but note that this may cause normal shell behavior to be sup- pressed. In particular, ``-d ~'' (tilde) is expanded by Unix C shells into the name of the user's home directory, but ``-d~'' is treated as a literal subdirec- tory ``~'' of the current directory. unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current directory to /tmp/bar/ --------------- jimage and jmod --------------- The jimage and jmod as you note use the --dir option for extracting to that specified directory. Those were the tools I looked at. I think using the -d option with -x for the jar command is ruled out since it already is used for a different purpose, although for a different "main" operation of the jar command. As for using --dir for this new feature, I don't think it alone will be enough. Specifically, I couldn't find a "short form" option for the --dir option in the jimage or jmod commands. For the jar extract feature that we are discussing here, I think having a short form option (in addition to the longer form) is necessary to have it match the usage expectations of similar other options that the jar command exposes. So even if we do choose --dir as the long form option, we would still need a short form for it and since -d is already taken for something else, we would still need to come up with a different one. The short form of this option could be -C (see below). I think reusing the -C option, for this new feature, perhaps is a good thing. The -C is currently used by the update and create "main" operation of the jar command and the man page for this option states: -C dir When creating (c) or updating (u) a JAR file, this option temporarily changes the directory while processing files specified by the file operands. Its operation is intended to be similar to the -C option of the UNIX tar utility.For example, the following command changes to the classes directory and adds the Bar.class file from that directory to my.jar: jar uf my.jar -C classes Bar.class .... Using the -C option would indeed align it with the tar command. For the "long form" of this option, the tar command (both on MacOS and CentOS) uses --directory. For this jar extract feature though, we could perhaps just use --dir to have it align with the jimage and the jmod tools. So I think the combination of -C (short form) and --dir (long form) would perhaps be suitable for this feature. There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools. I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify: unzip foo.zip -d /tmp/blah/ and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it. However, unzip foo.zip -d /tmp/blah/hello/ and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories. Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like: jimage extract --dir /tmp/blah/foo/bar/ jdkmodules will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image. From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands. One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jiefu at openjdk.java.net Sun Feb 28 13:34:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 28 Feb 2021 13:34:47 GMT Subject: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5] In-Reply-To: References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com> <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com> Message-ID: On Sat, 27 Feb 2021 11:15:06 GMT, Jie Fu wrote: >> test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42: >> >>> 40: * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector >>> 41: * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest >>> 42: * @run testng/othervm -XX:MaxVectorSize=4 PreferredSpeciesTest >> >> `-XX:MaxVectorSize` is C2-specific. It's better to specify either `-XX:-IgnoreUnrecognizedVMOptions` or `@requires vm.compiler2.enabled`. > > `@requires vm.compiler2.enabled` had been added. > Thanks. @PaulSandoz , are you also OK with the latest version? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722