From iklam at openjdk.java.net Tue Dec 1 01:14:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 01:14:55 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: <3wo_c-mOOD6m5wBMpO6uDXEi1SPBxAREMp8ai-814pY=.8f0a5223-a9ac-47e7-8c43-e1095e2aa3c6@github.com> On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold LGTM. Thanks for fixing the CDS tests. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:18:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:18:54 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Hi Harold, I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:33:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:33:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:16:11 GMT, David Holmes wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Hi Harold, > I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. > Thanks, > David I should clarify this. I suggested in the bug report that we could continue to print the -Xlog equivalents, but when I wrote that I was thinking that the existing deprecated-aliased code would simply be changed to obsoleted-aliased code. I didn't consider that we might need to keep the deprecated-aliased code for future conversions to UL. But I can see now that we might want to do that. In which case I'd prefer to no longer print the -Xlog equivalents, rather than duplicate the deprecated-aliased code into an obsolete-aliased form. My intent was to get rid of this special aliased flag handling code in the near future. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From iklam at openjdk.java.net Tue Dec 1 01:54:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 01:54:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 07:21:13 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix gtest for MacOS and AIX LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1390 From david.holmes at oracle.com Tue Dec 1 02:34:17 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 12:34:17 +1000 Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v3] In-Reply-To: References: Message-ID: <913959c4-3319-9cf4-11e0-1504bb0cfdae@oracle.com> On 1/12/2020 3:11 am, Thomas Stuefe wrote: > On Mon, 30 Nov 2020 15:24:12 GMT, Jie Fu wrote: > >>> Hi all, >>> >>> The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. >>> It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. >>> >>> Any comments? >>> >>> Thanks. >>> Best regards, >>> Jie >>> >>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 >>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 >> >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Inline add_len > > Looks fine. > > I guess another solution would have been > > #define MSGFMT "Index %d out of bounds for length %d" > #define add_len sizeof(MSGFMT) I didn't realize that would work. I thought the use of the string literal would decay into a "const char * const" and thus sizeof would give the size of the pointer. > .. > char message[2 * jintAsStringSize + add_len]; Except you subtract four for the two %d ocurrences. David ----- > .. > jio_snprintf(message, sizeof(message), MSGFMT, \ > ... > to spare you the character counting > > ------------- > > Marked as reviewed by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1518 > From jiefu at openjdk.java.net Tue Dec 1 03:41:54 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 1 Dec 2020 03:41:54 GMT Subject: Integrated: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:24:12 GMT, Jie Fu wrote: > Hi all, > > The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. > It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. > > Any comments? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 This pull request has now been integrated. Changeset: 0eaf0bbe Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/0eaf0bbe Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr Reviewed-by: shade, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From ysuenaga at openjdk.java.net Tue Dec 1 04:37:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 04:37:07 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c Message-ID: `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) We can see the warning on `make test-image` as below: * Fedora 33 x86_64 * gcc: gcc-10.2.1-6.fc33.x86_64 * glibc: glibc-2.32-2.fc33.x86_64 245 | sigset(signal_num, handler); | ^~~~~~ In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW | ^~~~~~ cc1: all warnings being treated as errors gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 gmake[3]: *** Waiting for unfinished jobs.... gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 ------------- Commit messages: - 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c Changes: https://git.openjdk.java.net/jdk/pull/1529/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257467 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1529.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1529/head:pull/1529 PR: https://git.openjdk.java.net/jdk/pull/1529 From dholmes at openjdk.java.net Tue Dec 1 04:49:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 04:49:59 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> On Thu, 19 Nov 2020 19:27:20 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix Copyright year Changes requested by dholmes (Reviewer). src/hotspot/share/logging/logTagSet.cpp line 131: > 129: log(level, buf); > 130: } else { > 131: // Buffer too small, allocate a large enough buffer by using of malloc/free to avoid circularity. s/by using of/using/ src/hotspot/share/logging/logTagSet.cpp line 139: > 137: log(level, newbuf); > 138: ::free(newbuf); > 139: } else { If we failed to allocate newbuf the existing buf is already filled with everything we need. Can't we just overwrite the last part with the "truncated" message rather than re-doing the whole thing? ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Dec 1 04:50:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 04:50:02 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 18 Nov 2020 05:15:41 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use malloc/free for large log message buffer > > src/hotspot/share/logging/logTagSet.cpp line 129: > >> 127: if ((size_t)ret >= sizeof(buf)) { >> 128: size_t newbuf_len = prefix_len + ret + 1; >> 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); > > Do we need to zero the array with calloc? > The `(char*)` cast shouldn't be needed. The calloc query has not been addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Dec 1 04:57:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 04:57:56 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:38:44 GMT, Yasumasa Suenaga wrote: > `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) > > We can see the warning on `make test-image` as below: > > * Fedora 33 x86_64 > * gcc: gcc-10.2.1-6.fc33.x86_64 > * glibc: glibc-2.32-2.fc33.x86_64 > > > > 245 | sigset(signal_num, handler); > | ^~~~~~ > In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: > > 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW > | ^~~~~~ > cc1: all warnings being treated as errors > gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 I would suggest we just delete the sigset usage as it is obsolete. The whole point of this test is to test signal chaining for the VM and sigset is undefined for a multi-threaded process (POSIX spec.) The use of sigaction suffices IMO. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1529 From minqi at openjdk.java.net Tue Dec 1 05:34:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 05:34:56 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> On Tue, 1 Dec 2020 04:43:58 GMT, David Holmes wrote: >> src/hotspot/share/logging/logTagSet.cpp line 129: >> >>> 127: if ((size_t)ret >= sizeof(buf)) { >>> 128: size_t newbuf_len = prefix_len + ret + 1; >>> 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); >> >> Do we need to zero the array with calloc? >> The `(char*)` cast shouldn't be needed. > > The calloc query has not been addressed. malloc/calloc return void* so need this cast. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Tue Dec 1 05:34:59 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 05:34:59 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 04:43:21 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Copyright year > > src/hotspot/share/logging/logTagSet.cpp line 131: > >> 129: log(level, buf); >> 130: } else { >> 131: // Buffer too small, allocate a large enough buffer by using of malloc/free to avoid circularity. > > s/by using of/using/ will address. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Tue Dec 1 05:38:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 05:38:57 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 04:46:43 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Copyright year > > src/hotspot/share/logging/logTagSet.cpp line 139: > >> 137: log(level, newbuf); >> 138: ::free(newbuf); >> 139: } else { > > If we failed to allocate newbuf the existing buf is already filled with everything we need. Can't we just overwrite the last part with the "truncated" message rather than re-doing the whole thing? line 124: When buf is small, buf is filled with whatever truncated string with format to get the length needed for new buffer, it does not include prefix. The new version keeps prefix and the buf ends with "..(truncated), native OOM" even if prefix already overflows buf. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From ysuenaga at openjdk.java.net Tue Dec 1 06:00:13 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 06:00:13 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v2] In-Reply-To: References: Message-ID: > `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) > > We can see the warning on `make test-image` as below: > > * Fedora 33 x86_64 > * gcc: gcc-10.2.1-6.fc33.x86_64 > * glibc: glibc-2.32-2.fc33.x86_64 > > > > 245 | sigset(signal_num, handler); > | ^~~~~~ > In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: > > 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW > | ^~~~~~ > cc1: all warnings being treated as errors > gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove sigset() from signal handler tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1529/files - new: https://git.openjdk.java.net/jdk/pull/1529/files/99b266c6..21437c3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=00-01 Stats: 15 lines in 3 files changed: 0 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1529.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1529/head:pull/1529 PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Tue Dec 1 06:00:14 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 06:00:14 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 04:54:49 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove sigset() from signal handler tests > > I would suggest we just delete the sigset usage as it is obsolete. The whole point of this test is to test signal chaining for the VM and sigset is undefined for a multi-threaded process (POSIX spec.) The use of sigaction suffices IMO. > Thanks, > David It's better if we can remove `sigset()` from signal handler tests. So I did that in new commit. Could you review again? This commit passed hotspot/jtreg/runtime/signal tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From david.holmes at oracle.com Tue Dec 1 06:12:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 06:12:33 +0000 (UTC) Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> Message-ID: <02d0d39d-7822-5317-1362-18bcaff81709@oracle.com> On 1/12/2020 3:34 pm, Yumin Qi wrote: > On Tue, 1 Dec 2020 04:43:58 GMT, David Holmes wrote: > >>> src/hotspot/share/logging/logTagSet.cpp line 129: >>> >>>> 127: if ((size_t)ret >= sizeof(buf)) { >>>> 128: size_t newbuf_len = prefix_len + ret + 1; >>>> 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); >>> >>> Do we need to zero the array with calloc? >>> The `(char*)` cast shouldn't be needed. >> >> The calloc query has not been addressed. > > malloc/calloc return void* so need this cast. That wasn't the query I meant - I meant why calloc not malloc? Why do we need to zero this memory? Is that just to avoid needing to figure out if we have to NUL terminate ourselves somewhere? On the cast, in C you would not need it, but in C++ you do. I still tend to recall C rules. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1246 > From dholmes at openjdk.java.net Tue Dec 1 06:30:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 06:30:58 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 05:36:25 GMT, Yumin Qi wrote: >> src/hotspot/share/logging/logTagSet.cpp line 139: >> >>> 137: log(level, newbuf); >>> 138: ::free(newbuf); >>> 139: } else { >> >> If we failed to allocate newbuf the existing buf is already filled with everything we need. Can't we just overwrite the last part with the "truncated" message rather than re-doing the whole thing? > > line 124: When buf is small, buf is filled with whatever truncated string with format to get the length needed for new buffer, it does not include prefix. The new version keeps prefix and the buf ends with "..(truncated), native OOM" even if prefix already overflows buf. Ah I missed that. But do we need to do that? If we introduce: `char buf2[1];` at line 123 and use that to determine the necessary additional length, then we don't need to re-start the whole process from scratch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Dec 1 06:34:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 06:34:59 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:00:13 GMT, Yasumasa Suenaga wrote: >> `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) >> >> We can see the warning on `make test-image` as below: >> >> * Fedora 33 x86_64 >> * gcc: gcc-10.2.1-6.fc33.x86_64 >> * glibc: glibc-2.32-2.fc33.x86_64 >> >> >> >> 245 | sigset(signal_num, handler); >> | ^~~~~~ >> In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: >> >> 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW >> | ^~~~~~ >> cc1: all warnings being treated as errors >> gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove sigset() from signal handler tests Just eradicate "mode" completely. Thanks, David test/hotspot/jtreg/runtime/signal/README line 40: > 38: > 39: Signal handlers don't do anything, so the only fact that signal handler was called is checked. > 40: Also 2 different ways of setting signal handlers are tested: sigaction. There is only one way now so delete this sentence. test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 96: > 94: boolean passed = true; > 95: > 96: for (String mode : new String[] {"sigaction"}) { You don't need the loop any more. You don't need to pass a "mode" any more. test/hotspot/jtreg/runtime/signal/exesigtest.c line 147: > 145: boolean isSupportedSigMode () > 146: { > 147: if ( !strcmp(mode, "sigaction") ) You can delete the whole "mode" logic. ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Tue Dec 1 07:02:10 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 07:02:10 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: References: Message-ID: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> > `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) > > We can see the warning on `make test-image` as below: > > * Fedora 33 x86_64 > * gcc: gcc-10.2.1-6.fc33.x86_64 > * glibc: glibc-2.32-2.fc33.x86_64 > > > > 245 | sigset(signal_num, handler); > | ^~~~~~ > In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: > > 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW > | ^~~~~~ > cc1: all warnings being treated as errors > gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove -mode option from sigtest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1529/files - new: https://git.openjdk.java.net/jdk/pull/1529/files/21437c3a..19c35bba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=01-02 Stats: 78 lines in 3 files changed: 3 ins; 37 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/1529.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1529/head:pull/1529 PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Tue Dec 1 07:05:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 07:05:55 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 06:32:14 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove sigset() from signal handler tests > > Just eradicate "mode" completely. > > Thanks, > David @dholmes-ora Thanks for your comment! I fixed them in new commit. Could you check again? This commit passed hotspot/jtreg/runtime/signal tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From stuefe at openjdk.java.net Tue Dec 1 07:13:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 07:13:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:51:57 GMT, Ioi Lam wrote: > LGTM Thanks, Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From jiefu at openjdk.java.net Tue Dec 1 07:24:18 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 1 Dec 2020 07:24:18 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v2] In-Reply-To: References: Message-ID: <9o_FHDCBzJ72slxwHUDW88J2skp_jsYN9Ll8UfgwDc4=.46bac349-8d9e-4f2c-8fc5-30afeaec0ce2@github.com> > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 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 four additional commits since the last revision: - Refinement & jtreg test - Merge branch 'master' into JDK-8257230 - Merge branch 'master' into JDK-8257230 - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1492/files - new: https://git.openjdk.java.net/jdk/pull/1492/files/545d89a1..0389bc4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=00-01 Stats: 13070 lines in 264 files changed: 8989 ins; 2442 del; 1639 mod Patch: https://git.openjdk.java.net/jdk/pull/1492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492 PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Tue Dec 1 07:29:02 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 1 Dec 2020 07:29:02 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v2] In-Reply-To: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> References: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> Message-ID: <_4GNImOBUb3blpdvanP_ipNRxS1CgI5_NkTObuyF6ig=.3ebdafee-db84-4485-beb5-4c90fef36c14@github.com> On Mon, 30 Nov 2020 13:42:56 GMT, Thomas Schatzl wrote: > I think the change is good, but please add a test for this. > > E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. The jtreg test had been added. And the fix had been refined based on @kstefanj 's suggestion. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Tue Dec 1 07:29:03 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 1 Dec 2020 07:29:03 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 23:31:20 GMT, Jie Fu wrote: >> I agree that the fix is in line with the current code and I guess setting `MinHeapSize` should override `MaxVirtMemFraction` and allow us to use more than half the address space specified. >> >> In this case I think I would prefer moving the the call `limit_by_allocatable_memory(reasonable_initial);` [1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting. >> >> Makes sense? Or will that lead to some other problem? >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1902 > >> >> In this case I think I would prefer moving the the call `limit_by_allocatable_memory(reasonable_initial);` [1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting. >> > > Good suggestion! > > Will test it soon. > Thanks. No regression. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From stuefe at openjdk.java.net Tue Dec 1 11:16:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 11:16:17 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Print a short snippet for unknown mappings - Merge - Fix gtest for MacOS and AIX - Merge - Initial patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/be7acf6c..e2b71654 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=02-03 Stats: 14114 lines in 328 files changed: 9461 ins; 2685 del; 1968 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From ysuenaga at openjdk.java.net Tue Dec 1 11:17:57 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 11:17:57 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 07:02:55 GMT, Yasumasa Suenaga wrote: >> Just eradicate "mode" completely. >> >> Thanks, >> David > > @dholmes-ora Thanks for your comment! I fixed them in new commit. Could you check again? > This commit passed hotspot/jtreg/runtime/signal tests. Linux x64 tier1 test (runtime/handshake/HandshakeWalkStackTest.java) failed, but it does not seem to cause by this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From coleenp at openjdk.java.net Tue Dec 1 12:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. src/hotspot/share/runtime/arguments.cpp line 617: > 615: #ifndef PRODUCT > 616: // These options are removed in jdk9. Remove this code for jdk10. > 617: static AliasedFlag const removed_develop_logging_flags[] = { I think this removed_develop_logging_flags infrastructure should be removed. src/hotspot/share/runtime/arguments.cpp line 612: > 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, > 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, > 612: { NULL, NULL, NULL, NULL } I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. src/hotspot/share/runtime/arguments.cpp line 1325: > 1323: *arg == '+' ? obs_replacement->tag_name : "off"); > 1324: return true; > 1325: } I see you left this empty in case we change more flags to logging flags. I don't see any Trace flags left that users would care about that merit this amount of helpfulness. I think this should be removed too. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Tue Dec 1 12:26:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:26:56 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: <29qFQfdT8aRoYd7OommDPT2109CjBFK4SfkY40eFdF4=.0e5bee3e-553d-4324-b62a-91472592a278@github.com> On Tue, 24 Nov 2020 22:39:08 GMT, David Holmes wrote: >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore volatile modifier Still looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1402 From coleenp at openjdk.java.net Tue Dec 1 12:26:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:26:58 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 08:46:40 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore volatile modifier > > src/hotspot/share/runtime/mutex.hpp line 90: > >> 88: // than the lock owner are inherently racy. >> 89: Thread* volatile _owner; >> 90: void raw_set_owner(Thread* new_owner) { Atomic::store(&_owner, new_owner); } > > set_owner_relaxed might be a better name. Your call... Don't like 'relaxed'. I'm not a huge fan of raw, since it's not raw here, but leave it. It's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From coleenp at openjdk.java.net Tue Dec 1 12:26:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:26:59 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:21:58 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/mutex.hpp line 90: >> >>> 88: // than the lock owner are inherently racy. >>> 89: Thread* volatile _owner; >>> 90: void raw_set_owner(Thread* new_owner) { Atomic::store(&_owner, new_owner); } >> >> set_owner_relaxed might be a better name. Your call... > > Don't like 'relaxed'. I'm not a huge fan of raw, since it's not raw here, but leave it. It's fine. Thanks for restoring 'volatile'. ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From thomas.stuefe at gmail.com Tue Dec 1 12:39:34 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Dec 2020 13:39:34 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Message-ID: Hi, may I please have reviews for the following downport: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35.diff Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff The original patch does not apply cleanly since this function had been heavily reworked. I rewrote it from scratch, but since the problem is simple this should be simple to review. Thanks, Thomas From stuefe at openjdk.java.net Tue Dec 1 13:07:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 13:07:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:51:57 GMT, Ioi Lam wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix gtest for MacOS and AIX > > LGTM @iklam Could you please take a small look at the last commit? After your Windbg exercises in JDK-8255917 I decided to buff the printout of the mapping. Nothing too complicated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Tue Dec 1 13:07:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 13:07:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 13:03:22 GMT, Thomas Stuefe wrote: >> LGTM > > @iklam Could you please take a small look at the last commit? After your Windbg exercises in JDK-8255917 I decided to buff the printout of the mapping. Nothing too complicated. [mapping-printout.txt](https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt) This is an example of the mapping printout for a full process ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From rrich at openjdk.java.net Tue Dec 1 13:45:09 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 1 Dec 2020 13:45:09 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v2] In-Reply-To: References: Message-ID: > This is an XS sized patch to get a zerobased compressed class space on > Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. > > On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one > attempt is made to place the CCS right after the heap which will be at 4g > (ELF_ET_DYN_BASE) but there the java launcher is already mapped. > > This change reuses the search already implemented for AARCH64. > > Master without Fix Master with Fix > > -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space > ---------------------------------------------------------------------------------------------------- > 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 > 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 > 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 > 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 > 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Special case for AIX in largeHeapTest(). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1512/files - new: https://git.openjdk.java.net/jdk/pull/1512/files/d8e6d143..c78783cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1512&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1512&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1512/head:pull/1512 PR: https://git.openjdk.java.net/jdk/pull/1512 From rrich at openjdk.java.net Tue Dec 1 14:06:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 1 Dec 2020 14:06:55 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v2] In-Reply-To: References: Message-ID: <1Dd2YRhYe4y5KL2FdN16p6OWflxlXJuOyuhsnh4wAhw=.7b470278-c1d7-4dc8-bb02-a18aa025b6bb@github.com> On Mon, 30 Nov 2020 11:00:21 GMT, Martin Doerr wrote: > > > Thanks for fixing it! Looks good to me, too. Was it tested on AIX? Yes, it was tested on AIX. I've overlooked a failure though, sorry... The test CompressedClassPointers.largeHeapTest() fails on AIX because it manages to get a zerobased CCS which is unexpected. Actually a zerobased CCS is good but we get it accidentally because the first attempt to place it behind the heap which is located above 32g fails. On Linux/PPC this test succeeds because this first attempt to allocate a high CCS succeeds which is actually not optimal. For now I excluded the narrow klass base test on AIX (as it was before). As an enhancement the first attempt to reserve address space for CCS should be below 32g if the coops heap was placed above 32g. I will open a JBS item for this. Thanks for the review. I will report back on the test results. ------------- PR: https://git.openjdk.java.net/jdk/pull/1512 From stuefe at openjdk.java.net Tue Dec 1 14:10:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 14:10:57 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v2] In-Reply-To: References: Message-ID: <7GcPQHwIFlxySeW8TRXBVKNLC9-qSDgW-PHfeC7O8QU=.e510674b-51bb-4f31-a0c7-b73f49376ae4@github.com> On Tue, 1 Dec 2020 13:45:09 GMT, Richard Reingruber wrote: >> This is an XS sized patch to get a zerobased compressed class space on >> Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. >> >> On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one >> attempt is made to place the CCS right after the heap which will be at 4g >> (ELF_ET_DYN_BASE) but there the java launcher is already mapped. >> >> This change reuses the search already implemented for AARCH64. >> >> Master without Fix Master with Fix >> >> -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space >> ---------------------------------------------------------------------------------------------------- >> 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 >> 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 >> 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 >> 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 >> 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 >> 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 >> 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Special case for AIX in largeHeapTest(). small nits; leave it up to you if you follow up on them. LGTM otherwise. Also, (T)rivial :) test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 103: > 101: if (testNarrowKlassBase() && !Platform.isAix()) { > 102: // AIX: the heap cannot be placed below 32g. The first attempt to > 103: // place the CCS after the heap fails (luckily). Finally CCS is small nits: s/after/behind s/Finally/Eventually or Subsequently test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 106: > 104: // successfully placed below 32g. So we get 0x0 as narrow klass > 105: // base. As an enhancement the first attempt mapping the CCS should > 106: // be made below 32g if oops are compressed but the heap is above 32g. I'd remove the enhancement remark since it is slightly confusing and irrelevant to the test in its current form. If you want to mention it, could you please create a JBS issue and mention it here ("see also JDK-xxxx"). ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1512 From rrich at openjdk.java.net Tue Dec 1 14:50:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 1 Dec 2020 14:50:13 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v3] In-Reply-To: References: Message-ID: > This is an XS sized patch to get a zerobased compressed class space on > Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. > > On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one > attempt is made to place the CCS right after the heap which will be at 4g > (ELF_ET_DYN_BASE) but there the java launcher is already mapped. > > This change reuses the search already implemented for AARCH64. > > Master without Fix Master with Fix > > -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space > ---------------------------------------------------------------------------------------------------- > 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 > 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 > 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 > 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 > 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Changes based on Thomas' feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1512/files - new: https://git.openjdk.java.net/jdk/pull/1512/files/c78783cc..96016bc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1512&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1512&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1512/head:pull/1512 PR: https://git.openjdk.java.net/jdk/pull/1512 From rrich at openjdk.java.net Tue Dec 1 14:50:14 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 1 Dec 2020 14:50:14 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v2] In-Reply-To: <7GcPQHwIFlxySeW8TRXBVKNLC9-qSDgW-PHfeC7O8QU=.e510674b-51bb-4f31-a0c7-b73f49376ae4@github.com> References: <7GcPQHwIFlxySeW8TRXBVKNLC9-qSDgW-PHfeC7O8QU=.e510674b-51bb-4f31-a0c7-b73f49376ae4@github.com> Message-ID: <0cL6BD6sGcIWiem0qN-TW6FSEGHJ6YiTETzviVM5K-o=.25c86831-91db-4275-ae86-6d845943496d@github.com> On Tue, 1 Dec 2020 14:03:05 GMT, Thomas Stuefe wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Special case for AIX in largeHeapTest(). > > test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 103: > >> 101: if (testNarrowKlassBase() && !Platform.isAix()) { >> 102: // AIX: the heap cannot be placed below 32g. The first attempt to >> 103: // place the CCS after the heap fails (luckily). Finally CCS is > > small nits: > s/after/behind > s/Finally/Eventually or Subsequently Done. > test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 106: > >> 104: // successfully placed below 32g. So we get 0x0 as narrow klass >> 105: // base. As an enhancement the first attempt mapping the CCS should >> 106: // be made below 32g if oops are compressed but the heap is above 32g. > > I'd remove the enhancement remark since it is slightly confusing and irrelevant to the test in its current form. If you want to mention it, could you please create a JBS issue and mention it here ("see also JDK-xxxx"). I removed it. I'll create the JBS item after some initial tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1512 From stuefe at openjdk.java.net Tue Dec 1 15:38:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 15:38:59 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Thu, 19 Nov 2020 19:27:20 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix Copyright year src/hotspot/share/logging/logTagSet.cpp line 127: > 125: } > 126: assert(ret >= 0, "Log message buffer issue"); > 127: size_t newbuf_len = (size_t)ret + prefix_len + 1; // total bytes needed including prefix. After the assert, I would return if ret < 0 to capture the release path. Otherwise you could end up malloc'ing a buffer which is too short by one char. src/hotspot/share/logging/logTagSet.cpp line 128: > 126: assert(ret >= 0, "Log message buffer issue"); > 127: size_t newbuf_len = (size_t)ret + prefix_len + 1; // total bytes needed including prefix. > 128: if (newbuf_len <= sizeof(buf)) { Hey, I just noted that your patch fixes a subtle bug here if we print with a large prefix `prefix_len > vwrite_buffer_size` but a small message `ret < sizeof(buf)`: Before, the code would have printed just the message without the prefix. Now, we correctly go into the malloc path. src/hotspot/share/logging/logTagSet.cpp line 146: > 144: prefix_len = _write_prefix(buf, sizeof(buf)); > 145: if (prefix_len < sizeof(buf)) { > 146: ret = os::vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args); Don't you need to use saved_args here? Original args pointer is already invalid. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From stuefe at openjdk.java.net Tue Dec 1 15:39:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 15:39:00 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 06:22:55 GMT, David Holmes wrote: >> line 124: When buf is small, buf is filled with whatever truncated string with format to get the length needed for new buffer, it does not include prefix. The new version keeps prefix and the buf ends with "..(truncated), native OOM" even if prefix already overflows buf. > > Ah I missed that. But do we need to do that? If we introduce: > `char buf2[1];` > at line 123 and use that to determine the necessary additional length, then we don't need to re-start the whole process from scratch. I agree, that would be easier: - at line 124, print into a dummy buffer of len 1. That gives you the length of the expanded string, but leaves the (truncated) prefix in buf intact. According to C99 a one should even be able to use a `NULL, 0` for the buffer but I am not sure where we are with os::vnsprintf. - Then, at line 140ff, buf contains either just the truncated prefix (line 124) or the truncated prefix + message (122). You then just stamp your truncated message over it. Only, make sure (maybe static assert) that the truncation text is smaller than the buffer :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From stuefe at openjdk.java.net Tue Dec 1 15:39:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 15:39:03 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 1 Dec 2020 15:21:05 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Copyright year > > src/hotspot/share/logging/logTagSet.cpp line 146: > >> 144: prefix_len = _write_prefix(buf, sizeof(buf)); >> 145: if (prefix_len < sizeof(buf)) { >> 146: ret = os::vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args); > > Don't you need to use saved_args here? Original args pointer is already invalid. But if you go with David's proposal this printf becomes unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From mdoerr at openjdk.java.net Tue Dec 1 15:43:02 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 1 Dec 2020 15:43:02 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:50:13 GMT, Richard Reingruber wrote: >> This is an XS sized patch to get a zerobased compressed class space on >> Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. >> >> On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one >> attempt is made to place the CCS right after the heap which will be at 4g >> (ELF_ET_DYN_BASE) but there the java launcher is already mapped. >> >> This change reuses the search already implemented for AARCH64. >> >> Master without Fix Master with Fix >> >> -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space >> ---------------------------------------------------------------------------------------------------- >> 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 >> 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 >> 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 >> 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 >> 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 >> 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 >> 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 >> 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Changes based on Thomas' feedback. Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1512 From stuefe at openjdk.java.net Tue Dec 1 15:56:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 15:56:04 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: References: Message-ID: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> On Thu, 19 Nov 2020 05:26:13 GMT, Yasumasa Suenaga wrote: >> If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. >> >> `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. >> We should check them, and should report what happened if error occurred. >> >> >> How to reproduce on Linux: >> >> 1. Mount tmpfs with 512K >> >> $ mkdir /tmp/tmp >> $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp >> >> 2. Run `java` with `-Xlog` >> >> $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - refactoring > - Merge branch 'master' into JDK-8256008 > - Fix typo > - 8256008: UL does not report anything if disk writing fails Hi Yasumasa, this is good, but some nits remain, see below. Cheers, Thomas src/hotspot/share/logging/logFileStreamOutput.cpp line 90: > 88: }; > 89: > 90: static bool write_error_is_shown = false; Can you make this a static member of LogFileStreamOutput please? src/hotspot/share/logging/logFileStreamOutput.cpp line 106: > 104: } > 105: > 106: #define WRITE_LOG_WITH_RESULT_CHECK(op, total) \ You may leave out total and reference "written" directly in the macro since its always used with "written". Leave it up to you though, its a matter of taste. src/hotspot/share/logging/logFileStreamOutput.cpp line 109: > 107: { \ > 108: int result = op; \ > 109: if (result <= 0) { \ May be not completely correct for all values of op: - fprintf returns a negative value (0 is valid if length to write was 0). I did not check jio_fprintf but I assume the return semantics are the same? - write_decorations returns 0 if it did not write any decorations, which is valid ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1106 From stuefe at openjdk.java.net Tue Dec 1 15:56:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 15:56:05 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> References: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> Message-ID: On Tue, 1 Dec 2020 15:41:50 GMT, Thomas Stuefe wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - refactoring >> - Merge branch 'master' into JDK-8256008 >> - Fix typo >> - 8256008: UL does not report anything if disk writing fails > > src/hotspot/share/logging/logFileStreamOutput.cpp line 90: > >> 88: }; >> 89: >> 90: static bool write_error_is_shown = false; > > Can you make this a static member of LogFileStreamOutput please? I also wonder whether this should not be a non-static member. Are there many streams? Isn't there one per output destination? If we stream to multiple files, we may want to see the error in each of the files. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From minqi at openjdk.java.net Tue Dec 1 16:49:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 16:49:57 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 1 Dec 2020 15:36:09 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logTagSet.cpp line 146: >> >>> 144: prefix_len = _write_prefix(buf, sizeof(buf)); >>> 145: if (prefix_len < sizeof(buf)) { >>> 146: ret = os::vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args); >> >> Don't you need to use saved_args here? Original args pointer is already invalid. > > But if you go with David's proposal this printf becomes unnecessary. Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Tue Dec 1 16:50:01 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 16:50:01 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 1 Dec 2020 15:17:02 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Copyright year > > src/hotspot/share/logging/logTagSet.cpp line 128: > >> 126: assert(ret >= 0, "Log message buffer issue"); >> 127: size_t newbuf_len = (size_t)ret + prefix_len + 1; // total bytes needed including prefix. >> 128: if (newbuf_len <= sizeof(buf)) { > > Hey, I just noted that your patch fixes a subtle bug here if we print with a large prefix `prefix_len > vwrite_buffer_size` but a small message `ret < sizeof(buf)`: > > Before, the code would have printed just the message without the prefix. Now, we correctly go into the malloc path. Yes, the original code has a bug here. > src/hotspot/share/logging/logTagSet.cpp line 127: > >> 125: } >> 126: assert(ret >= 0, "Log message buffer issue"); >> 127: size_t newbuf_len = (size_t)ret + prefix_len + 1; // total bytes needed including prefix. > > After the assert, I would return if ret < 0 to capture the release path. > Otherwise you could end up malloc'ing a buffer which is too short by one char. If we return if ret < 0, we should log the buf at least. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Tue Dec 1 16:50:02 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 1 Dec 2020 16:50:02 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 15:34:54 GMT, Thomas Stuefe wrote: >> Ah I missed that. But do we need to do that? If we introduce: >> `char buf2[1];` >> at line 123 and use that to determine the necessary additional length, then we don't need to re-start the whole process from scratch. > > I agree, that would be easier: > - at line 124, print into a dummy buffer of len 1. That gives you the length of the expanded string, but leaves the (truncated) prefix in buf intact. According to C99 a one should even be able to use a `NULL, 0` for the buffer but I am not sure where we are with os::vnsprintf. > - Then, at line 140ff, buf contains either just the truncated prefix (line 124) or the truncated prefix + message (122). You then just stamp your truncated message over it. > > Only, make sure (maybe static assert) that the truncation text is smaller than the buffer :) Thanks, it is using ::vnsprintf in os::vnsprintf, tested on linux, using NULL is OK but Windows counterpart is quite complex --- should avoid using 0 as length. I will be careful to use args and saved_args, they should only be used once --- it could be altered by call to ::vnsprintf. The patch already used it twice, now with David's suggestion, that usage will be eliminated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From ccheung at openjdk.java.net Tue Dec 1 19:38:01 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 19:38:01 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Message-ID: Please review this change which includes: - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. Testing: - [x] all cds/appcds tests locally on linux-x64 - [x] tiers 1 - 4 (in progress) ------------- Commit messages: - 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Changes: https://git.openjdk.java.net/jdk/pull/1542/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257241 Stats: 52 lines in 7 files changed: 2 ins; 11 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From mchung at openjdk.java.net Tue Dec 1 20:05:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 20:05:57 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) The change looks okay. Can you add a test to verify that it won't load from CDS archive if `disableEagerInitialization` is true? ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From iklam at openjdk.java.net Tue Dec 1 20:13:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:13:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:16:17 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Print a short snippet for unknown mappings > - Merge > - Fix gtest for MacOS and AIX > - Merge > - Initial patch Marked as reviewed by iklam (Reviewer). src/hotspot/os/windows/os_windows.cpp line 6002: > 6000: for (int i = 0; i < num_words; i++) { > 6001: v[i] = SafeFetch32((int*)p + i, errval); > 6002: if (v[i] == errval) { How about if (SafeFetch32((int*)p + i, 0x1234) == 0x1234 && SafeFetch32((int*)p + i, 0x5678) == 0x5678) { return; } else { v[i] = SafeFetch32((int*)p + i, 0); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Tue Dec 1 20:20:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:20:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: <1JQHQOm1UWJhx5ELnVNUUiCncnA33Yuj01sdxyTTvEs=.a1a910cf-bd4d-48a0-8168-293eb5748746@github.com> On Tue, 1 Dec 2020 20:09:38 GMT, Ioi Lam wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Print a short snippet for unknown mappings >> - Merge >> - Fix gtest for MacOS and AIX >> - Merge >> - Initial patch > > src/hotspot/os/windows/os_windows.cpp line 6002: > >> 6000: for (int i = 0; i < num_words; i++) { >> 6001: v[i] = SafeFetch32((int*)p + i, errval); >> 6002: if (v[i] == errval) { > > How about > if (SafeFetch32((int*)p + i, 0x1234) == 0x1234 && > SafeFetch32((int*)p + i, 0x5678) == 0x5678) { > return; > } else { > v[i] = SafeFetch32((int*)p + i, 0); > } Okay, I'll do that (minus the else part). I left it out because come on, its a 1 in 4 billion chance :) but the second SafeFetch only triggers when the first condition is true so this may still be cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From iklam at openjdk.java.net Tue Dec 1 20:21:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:21:55 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) LGTM. I agree with Mandy that we need a test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From stuefe at openjdk.java.net Tue Dec 1 20:34:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:34:09 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Ioi ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/e2b71654..de705074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From iklam at openjdk.java.net Tue Dec 1 20:39:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:39:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:34:09 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Ioi Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From redestad at openjdk.java.net Tue Dec 1 20:52:54 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Dec 2020 20:52:54 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Looks good to me! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1542 From hseigel at openjdk.java.net Tue Dec 1 21:44:09 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:44:09 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/9c373c6b..84e421f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=00-01 Stats: 206 lines in 3 files changed: 13 ins; 192 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Tue Dec 1 21:48:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:48:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:10:59 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. Thanks everyone for the reviews. Please review the updated commit which contains the following changes: 1. Moves most of the flags to the normal location for obsolete flags. 2. Keeps the extra -Xlog message for the three most commonly used flags. 3. Removes the removed_develop_logging_flags struct and support functions. 4. Removes the aliased_logging_flags struct and support functions based on Coleen's statement that there are no existing flags that would use it. Thanks! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From ccheung at openjdk.java.net Tue Dec 1 21:58:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 21:58:17 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <5kvJTqBrgXuMhMfr0h28756D9_yiyYLJPRYyybhDTcg=.0f1cc550-e763-4b11-bb6a-cae1d70e4f4d@github.com> On Tue, 1 Dec 2020 20:50:11 GMT, Claes Redestad wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > Looks good to me! @mlchung, @iklam, @cl4es Thanks for the review. I've added a test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 21:58:16 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 21:58:16 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: added a test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/812777b3..880407c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=00-01 Stats: 88 lines in 1 file changed: 88 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From mchung at openjdk.java.net Tue Dec 1 22:22:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 22:22:58 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:58:16 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > added a test test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: > 34: * @requires vm.cds > 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java I think it's better to make a copy of this test along side with this test. test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 77: > 75: .shouldHaveExitValue(0); > 76: > 77: // run with archive without the -Djdk.internal.lambda.disableEagerInitialization=true property Minor suggestion: make this test case in a separate `testWithEagerInitializationEnabled` method. `testImpl` can be renamed to `testWithEagerInitializationDisabled`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From iklam at openjdk.java.net Tue Dec 1 22:31:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:31:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From ccheung at openjdk.java.net Tue Dec 1 22:37:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 22:37:56 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:16:58 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: > >> 34: * @requires vm.cds >> 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java > > I think it's better to make a copy of this test along side with this test. I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From iklam at openjdk.java.net Tue Dec 1 22:50:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:50:00 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> On Tue, 1 Dec 2020 22:34:58 GMT, Calvin Cheung wrote: >> test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36: >> >>> 34: * @requires vm.cds >>> 35: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >>> 36: * @compile ../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java >> >> I think it's better to make a copy of this test along side with this test. > > I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. The `@compile` can be avoiding by putting LambdaEagerInitTest into the `@library` and referencing it as private static final String mainClass = LambdaEagerInitTest.class.getName(); ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From iklam at openjdk.java.net Tue Dec 1 23:00:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 23:00:56 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> Message-ID: On Tue, 1 Dec 2020 05:30:01 GMT, Yumin Qi wrote: >> The calloc query has not been addressed. > > malloc/calloc return void* so need this cast. calloc zero-fills the buffer. See https://en.cppreference.com/w/c/memory/calloc ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Dec 1 23:05:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 23:05:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:04:43 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 612: > >> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >> 612: { NULL, NULL, NULL, NULL } > > I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 23:13:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 23:13:56 GMT Subject: Integrated: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 23:08:28 GMT, David Holmes wrote: > Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. > > Thanks, > David This pull request has now been integrated. Changeset: 927504e8 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/927504e8 Stats: 25 lines in 2 files changed: 8 ins; 1 del; 16 mod 8256474: Migrate Mutex _owner accesses to use Atomic operations Reviewed-by: coleenp, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From ccheung at openjdk.java.net Tue Dec 1 23:16:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:16:13 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v3] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: 1. Make a copy of LambdaEagerInitTest.java to the test-classes dir 2. Modifications to LambdaEagerInit.java per review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/880407c1..edd4a094 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=01-02 Stats: 24 lines in 2 files changed: 11 ins; 2 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 23:26:00 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:26:00 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: References: Message-ID: <9QgNHvpiNC38l90LZoQC2kZpbzXv1YB7v5lmx_skBLk=.bfe1e254-9ffa-47e8-a3b7-381e1674357b@github.com> On Tue, 1 Dec 2020 22:19:55 GMT, Mandy Chung wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> added a test > > test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 77: > >> 75: .shouldHaveExitValue(0); >> 76: >> 77: // run with archive without the -Djdk.internal.lambda.disableEagerInitialization=true property > > Minor suggestion: make this test case in a separate `testWithEagerInitializationEnabled` method. `testImpl` can be renamed to `testWithEagerInitializationDisabled`. I also factored out the archive creation into the `createArchiveWithEagerInitializationEnabled` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Tue Dec 1 23:25:57 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 1 Dec 2020 23:25:57 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v2] In-Reply-To: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> References: <5SrwCM5wt1oa2h1Rg8lpC0YASOX70akzMQ8XYNpAjCo=.3f8219d7-ea70-4c28-b004-3c8a6e9cfed5@github.com> Message-ID: On Tue, 1 Dec 2020 22:47:18 GMT, Ioi Lam wrote: >> I can make a copy and put it under the `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still need the `@compile` and would be something like `@compile test-classes/LambdaEagerInitTest.java`. > > The `@compile` can be avoiding by putting LambdaEagerInitTest into the `@library` and referencing it as > > private static final String mainClass = LambdaEagerInitTest.class.getName(); Yes, `@library test-classes` works. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From mchung at openjdk.java.net Tue Dec 1 23:29:58 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Dec 2020 23:29:58 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:16:13 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Make a copy of LambdaEagerInitTest.java to the test-classes dir > 2. Modifications to LambdaEagerInit.java per review comments test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaEagerInitTest.java line 25: > 23: > 24: /** > 25: * @test This is part of LambdaEagerInit test. This does not need to be `@test` and so the entire comment block can be removed. If you want to verify, you could add a test case in LambdaEagerInit.java to run this main class without the CDS archive. ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From ysuenaga at openjdk.java.net Wed Dec 2 00:43:08 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 00:43:08 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v3] In-Reply-To: References: Message-ID: > If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. > > `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. > We should check them, and should report what happened if error occurred. > > > How to reproduce on Linux: > > 1. Mount tmpfs with 512K > > $ mkdir /tmp/tmp > $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp > > 2. Run `java` with `-Xlog` > > $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update PR * Move write_error_is_shown to private member in LogFileStreamOutput * Update condition at WRITE_LOG_WITH_RESULT_CHECK macro ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1106/files - new: https://git.openjdk.java.net/jdk/pull/1106/files/6b4bfc23..8f3f3f1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1106&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1106&range=01-02 Stats: 10 lines in 2 files changed: 2 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1106/head:pull/1106 PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Dec 2 00:43:09 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 00:43:09 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: References: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> Message-ID: On Tue, 1 Dec 2020 15:45:17 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logFileStreamOutput.cpp line 90: >> >>> 88: }; >>> 89: >>> 90: static bool write_error_is_shown = false; >> >> Can you make this a static member of LogFileStreamOutput please? > > I also wonder whether this should not be a non-static member. Are there many streams? Isn't there one per output destination? If we stream to multiple files, we may want to see the error in each of the files. Good catch! It should be a member of `LogFileStreamOutput`. I fixed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Dec 2 00:43:11 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 00:43:11 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> References: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> Message-ID: <1AEwtKX8HZqpMJVUTB75SrsKeGtTdnZaKlewADsaw_c=.f3fc54a9-5b96-4b24-95d7-fce01deb9577@github.com> On Tue, 1 Dec 2020 15:46:45 GMT, Thomas Stuefe wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - refactoring >> - Merge branch 'master' into JDK-8256008 >> - Fix typo >> - 8256008: UL does not report anything if disk writing fails > > src/hotspot/share/logging/logFileStreamOutput.cpp line 106: > >> 104: } >> 105: >> 106: #define WRITE_LOG_WITH_RESULT_CHECK(op, total) \ > > You may leave out total and reference "written" directly in the macro since its always used with "written". Leave it up to you though, its a matter of taste. I prefer that WRITE_LOG_WITH_RESULT_CHECK like a function, so I stay this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Dec 2 00:51:59 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 00:51:59 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> References: <-y-z3Pc7UXRrUbv6V15W5aYmsHYS1Nm7bYF3Ja2j8CA=.711f8f33-8519-47e0-9005-3ac908f8e6d7@github.com> Message-ID: On Tue, 1 Dec 2020 15:53:39 GMT, Thomas Stuefe wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - refactoring >> - Merge branch 'master' into JDK-8256008 >> - Fix typo >> - 8256008: UL does not report anything if disk writing fails > > Hi Yasumasa, > > this is good, but some nits remain, see below. > > Cheers, Thomas @tstuefe Thanks for your review! I updated PR. Could you review again? > src/hotspot/share/logging/logFileStreamOutput.cpp line 109: > >> 107: { \ >> 108: int result = op; \ >> 109: if (result <= 0) { \ > > May be not completely correct for all values of op: > - fprintf returns a negative value (0 is valid if length to write was 0). I did not check jio_fprintf but I assume the return semantics are the same? > - write_decorations returns 0 if it did not write any decorations, which is valid `jio_fprintf()` would call `vfprintf()`, so I concerned in case that `vfprintf()` cannot write enough. Callers of `jio_fprintf()` other than `write_decorations()` would write 1 byte at least. However `write_decorations()` might not write any chars, and also `vfprintf()` in glibc does not seem to return halfway value. So I updated condition to `< 0`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ccheung at openjdk.java.net Wed Dec 2 01:12:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 01:12:17 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: 1. Update comment block in LambdaEagerInitTest.java 2. Add more test cases using the default CDS archive in LambdaEagerInit.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/edd4a094..fc10e77f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=02-03 Stats: 46 lines in 2 files changed: 32 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From david.holmes at oracle.com Wed Dec 2 02:12:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2020 12:12:16 +1000 Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <-ofzsO_qxHnEBXHSk7kfi_dEg1gqRQMkPhTIW_BtD4k=.6c0933e3-62f6-426e-a2de-4df4fad04de2@github.com> Message-ID: <56767168-0bad-dea7-ab43-ac01e78ba2f7@oracle.com> On 2/12/2020 9:00 am, Ioi Lam wrote: > On Tue, 1 Dec 2020 05:30:01 GMT, Yumin Qi wrote: > >>> The calloc query has not been addressed. >> >> malloc/calloc return void* so need this cast. > > calloc zero-fills the buffer. See https://en.cppreference.com/w/c/memory/calloc Yes and the question was "why does it need to be zeroed?". David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1246 > From coleenp at openjdk.java.net Wed Dec 2 02:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:01:51 GMT, David Holmes wrote: >> src/hotspot/share/runtime/arguments.cpp line 612: >> >>> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >>> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >>> 612: { NULL, NULL, NULL, NULL } >> >> I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. > > Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Wed Dec 2 02:17:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:17:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I approve if you remove or leave the big 3 as aliases. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:44:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:11:35 GMT, Coleen Phillimore wrote: >> Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. > > For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. I think we should remove them. There is a risk that the user might not notice the difference between the old and new messages and so not realize they don't actually have active logging any more (until they go to access the logs to diagnose a problem). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:44:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I'm still pushing for treating all flags the same and removing all the aliased-flag code. Coleen seems to be okay either way. :) Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:54:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:54:57 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> References: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> Message-ID: On Tue, 1 Dec 2020 07:02:10 GMT, Yasumasa Suenaga wrote: >> `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) >> >> We can see the warning on `make test-image` as below: >> >> * Fedora 33 x86_64 >> * gcc: gcc-10.2.1-6.fc33.x86_64 >> * glibc: glibc-2.32-2.fc33.x86_64 >> >> >> >> 245 | sigset(signal_num, handler); >> | ^~~~~~ >> In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: >> >> 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW >> | ^~~~~~ >> cc1: all warnings being treated as errors >> gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove -mode option from sigtest Looks good to me! Perhaps @tstuefe could also take a look? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1529 From minqi at openjdk.java.net Wed Dec 2 04:09:07 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 2 Dec 2020 04:09:07 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v5] In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix according to review comments, use malloc replace calloc, also check return value from (v)snprintf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1246/files - new: https://git.openjdk.java.net/jdk/pull/1246/files/9a2f7b79..4d1cba14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=03-04 Stats: 30 lines in 1 file changed: 17 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Wed Dec 2 04:09:08 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 2 Dec 2020 04:09:08 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <5NCgKdnZBeX4FmX4oLqCiI4doZkimYtz8q6O3cA_W7E=.6708ef41-0b90-4099-b940-83c92d176827@github.com> Message-ID: On Tue, 1 Dec 2020 04:47:02 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Copyright year > > Changes requested by dholmes (Reviewer). > > > > > > malloc/calloc return void* so need this cast. > > That wasn't the query I meant - I meant why calloc not malloc? Why do we > need to zero this memory? Is that just to avoid needing to figure out if > we have to NUL terminate ourselves somewhere? > Changed to use malloc, also attached a test case to simulate OOM (see bug link). ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Wed Dec 2 04:17:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 04:17:00 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v5] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 2 Dec 2020 04:09:07 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix according to review comments, use malloc replace calloc, also check return value from (v)snprintf This seems okay to me now. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Wed Dec 2 04:31:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 2 Dec 2020 04:31:57 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v5] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 2 Dec 2020 04:14:00 GMT, David Holmes wrote: > This seems okay to me now. > > Thanks, > David Thanks for review again Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From iklam at openjdk.java.net Wed Dec 2 05:36:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 05:36:01 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 01:12:17 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Update comment block in LambdaEagerInitTest.java > 2. Add more test cases using the default CDS archive in LambdaEagerInit.java Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From stuefe at openjdk.java.net Wed Dec 2 06:25:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 06:25:57 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v3] In-Reply-To: References: Message-ID: <3aaS_0-mjiYOxGr5sEV3ATaySSsOQ6EhYYGQZBRFuy8=.159acaee-ee02-4b91-b63b-40f49a958136@github.com> On Wed, 2 Dec 2020 00:43:08 GMT, Yasumasa Suenaga wrote: >> If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. >> >> `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. >> We should check them, and should report what happened if error occurred. >> >> >> How to reproduce on Linux: >> >> 1. Mount tmpfs with 512K >> >> $ mkdir /tmp/tmp >> $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp >> >> 2. Run `java` with `-Xlog` >> >> $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update PR > * Move write_error_is_shown to private member in LogFileStreamOutput > * Update condition at WRITE_LOG_WITH_RESULT_CHECK macro Looks good to me now. Thanks for fixing! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1106 From stuefe at openjdk.java.net Wed Dec 2 06:39:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 06:39:02 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: References: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> Message-ID: <8jBYm6SmCIDySJpynCBZ7folRuyxshRq3aM4kene9NY=.44abcc01-b310-452c-b124-e6d5a6630840@github.com> On Wed, 2 Dec 2020 02:52:28 GMT, David Holmes wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -mode option from sigtest > > Looks good to me! > > Perhaps @tstuefe could also take a look? > > Thanks, > David Hi, sorry for chiming in too late, I did not see this before. I would not remove the sigset testing from this test unless we also remove the sigset chaining capability from libjsig. Otherwise we just ship untested functionality. So I'd say either go the full way and remove sigset() chaining from src/java.base/unix/native/libjsig/jsig.c. But that probably needs a CSR as well. Or we just go with Yasumasa's initial patch, just switching off the warning. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From stuefe at openjdk.java.net Wed Dec 2 06:56:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 06:56:59 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v5] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 2 Dec 2020 04:09:07 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix according to review comments, use malloc replace calloc, also check return value from (v)snprintf Looks good. Thank you for your perseverance. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Wed Dec 2 07:12:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 07:12:54 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: <8jBYm6SmCIDySJpynCBZ7folRuyxshRq3aM4kene9NY=.44abcc01-b310-452c-b124-e6d5a6630840@github.com> References: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> <8jBYm6SmCIDySJpynCBZ7folRuyxshRq3aM4kene9NY=.44abcc01-b310-452c-b124-e6d5a6630840@github.com> Message-ID: On Wed, 2 Dec 2020 06:36:17 GMT, Thomas Stuefe wrote: >> Looks good to me! >> >> Perhaps @tstuefe could also take a look? >> >> Thanks, >> David > > Hi, > > sorry for chiming in too late, I did not see this before. > > I would not remove the sigset testing from this test unless we also remove the sigset chaining capability from libjsig. Otherwise we just ship untested functionality. > > So I'd say either go the full way and remove sigset() chaining from src/java.base/unix/native/libjsig/jsig.c. But that probably needs a CSR as well. Or we just go with Yasumasa's initial patch, just switching off the warning. > > Cheers, Thomas Hi Thomas (@tstuefe ), Thanks for chiming in. I was ready to agree with you but something was nagging at me. Sure enough looking closer signal chaining supports three modes: sigset, sigaction and signal. But the test only tests sigset and sigaction - so we already have untested functionality. And that was because signal() use was broken and we removed it under: https://bugs.openjdk.java.net/browse/JDK-8165192 back in 2016. So we do have a precedence (perhaps a bad one) for removing test code without removing functional code. But I'm okay with going back to Yasumasa's original proposal to just fix the warning and filing a RFE to deprecate, then remove sigset and signal from the signal chaining mechanism. Thanks, David ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Wed Dec 2 07:31:15 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 07:31:15 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v4] In-Reply-To: References: Message-ID: > `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) > > We can see the warning on `make test-image` as below: > > * Fedora 33 x86_64 > * gcc: gcc-10.2.1-6.fc33.x86_64 > * glibc: glibc-2.32-2.fc33.x86_64 > > > > 245 | sigset(signal_num, handler); > | ^~~~~~ > In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: > > 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW > | ^~~~~~ > cc1: all warnings being treated as errors > gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Revert "Remove sigset() from signal handler tests" This reverts commit 21437c3a3fe043a95c47c18f9adc3f5c59109ccc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1529/files - new: https://git.openjdk.java.net/jdk/pull/1529/files/19c35bba..f2ca9e5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1529&range=02-03 Stats: 89 lines in 3 files changed: 48 ins; 3 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/1529.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1529/head:pull/1529 PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Wed Dec 2 07:35:56 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 07:35:56 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: References: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> <8jBYm6SmCIDySJpynCBZ7folRuyxshRq3aM4kene9NY=.44abcc01-b310-452c-b124-e6d5a6630840@github.com> Message-ID: On Wed, 2 Dec 2020 07:10:16 GMT, David Holmes wrote: > But I'm okay with going back to Yasumasa's original proposal to just fix the warning Reverted commits for removing sigset tests. > and filing a RFE to deprecate, then remove sigset and signal from the signal chaining mechanism. I can file it, but I wonder how we mark deprecate to sigset and signal? `#pragma` in each compilers? Or can we remove them immediately after CSR is approved? ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From stuefe at openjdk.java.net Wed Dec 2 08:06:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 08:06:58 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 07:31:15 GMT, Yasumasa Suenaga wrote: >> `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) >> >> We can see the warning on `make test-image` as below: >> >> * Fedora 33 x86_64 >> * gcc: gcc-10.2.1-6.fc33.x86_64 >> * glibc: glibc-2.32-2.fc33.x86_64 >> >> >> >> 245 | sigset(signal_num, handler); >> | ^~~~~~ >> In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: >> >> 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW >> | ^~~~~~ >> cc1: all warnings being treated as errors >> gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Remove sigset() from signal handler tests" > > This reverts commit 21437c3a3fe043a95c47c18f9adc3f5c59109ccc. LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1529 From stuefe at openjdk.java.net Wed Dec 2 08:06:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 08:06:59 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v3] In-Reply-To: References: <4xEwrYrwF8XHivyW1GMH_waynrtO-E-tFqFFeublu48=.910fcff5-e090-442c-86f9-01be8328b04a@github.com> <8jBYm6SmCIDySJpynCBZ7folRuyxshRq3aM4kene9NY=.44abcc01-b310-452c-b124-e6d5a6630840@github.com> Message-ID: <6IB5fREcJmqKoK7VixBVsBz9GFTiR1tzKxAWQPDfTr8=.b4c00af9-e70e-4f13-a6f4-d3944596fd71@github.com> On Wed, 2 Dec 2020 07:32:50 GMT, Yasumasa Suenaga wrote: > > But I'm okay with going back to Yasumasa's original proposal to just fix the warning > > Reverted commits for removing sigset tests. > > > and filing a RFE to deprecate, then remove sigset and signal from the signal chaining mechanism. > > I can file it, but I wonder how we mark deprecate to sigset and signal? `#pragma` in each compilers? > Or can we remove them immediately after CSR is approved? I think the official Oracle doc for signal chaining would have to be adapted (https://docs.oracle.com/javase/9/vm/signal-chaining.htm). ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From thomas.stuefe at gmail.com Wed Dec 2 08:30:46 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 Dec 2020 09:30:46 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Message-ID: Hi, I'd like to get reviews for the backport of the following fix: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff This patch had to be rewritten for 11 since most of the surroundings changed since 11 due to cleanups. But the patch itself is straightforward. Thank you, Thomas From ysuenaga at openjdk.java.net Wed Dec 2 08:31:54 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 08:31:54 GMT Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 08:04:27 GMT, Thomas Stuefe wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Remove sigset() from signal handler tests" >> >> This reverts commit 21437c3a3fe043a95c47c18f9adc3f5c59109ccc. > > LGTM > > > and filing a RFE to deprecate, then remove sigset and signal from the signal chaining mechanism. > > > > > > I can file it, but I wonder how we mark deprecate to sigset and signal? `#pragma` in each compilers? > > Or can we remove them immediately after CSR is approved? > > I think the official Oracle doc for signal chaining would have to be adapted (https://docs.oracle.com/javase/9/vm/signal-chaining.htm). Thanks @tstuefe ! Anyway, I will integrate this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From david.holmes at oracle.com Wed Dec 2 09:01:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2020 19:01:37 +1000 Subject: RFR: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c [v4] In-Reply-To: References: Message-ID: <2ddee778-03be-b98c-afda-d1bd194a1de7@oracle.com> On 2/12/2020 6:31 pm, Yasumasa Suenaga wrote: > On Wed, 2 Dec 2020 08:04:27 GMT, Thomas Stuefe wrote: > >>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Revert "Remove sigset() from signal handler tests" >>> >>> This reverts commit 21437c3a3fe043a95c47c18f9adc3f5c59109ccc. >> >> LGTM > >>>> and filing a RFE to deprecate, then remove sigset and signal from the signal chaining mechanism. >>> >>> >>> I can file it, but I wonder how we mark deprecate to sigset and signal? `#pragma` in each compilers? >>> Or can we remove them immediately after CSR is approved? >> >> I think the official Oracle doc for signal chaining would have to be adapted (https://docs.oracle.com/javase/9/vm/signal-chaining.htm). > > Thanks @tstuefe ! > Anyway, I will integrate this change. I've filed JDK-8257572 to update signal chaining too deprecate sigset and signal usage. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1529 > From ysuenaga at openjdk.java.net Wed Dec 2 09:08:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 09:08:55 GMT Subject: Integrated: 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:38:44 GMT, Yasumasa Suenaga wrote: > `sigset()` is deprecated, and `__attribute_deprecated_msg__` has been [set to the declaration in glibc](https://sourceware.org/git/?p=glibc.git;a=commit;f=signal/signal.h;h=02802fafcf6e11ea3f998f685035ffe568dfddeb) > > We can see the warning on `make test-image` as below: > > * Fedora 33 x86_64 > * gcc: gcc-10.2.1-6.fc33.x86_64 > * glibc: glibc-2.32-2.fc33.x86_64 > > > > 245 | sigset(signal_num, handler); > | ^~~~~~ > In file included from /home/ysuenaga/github-forked/jdk/test/hotspot/jtreg/runtime/signal/exesigtest.c:25: > > 353 | extern __sighandler_t sigset (int __sig, __sighandler_t __disp) __THROW > | ^~~~~~ > cc1: all warnings being treated as errors > gmake[3]: *** [test/JtregNativeHotspot.gmk:1525: /home/ysuenaga/github-forked/jdk/build/linux-x86_64-server-fastdebug/support/test/hotspot/jtreg/native/support/exesigtest/exesigtest.o] Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [make/Main.gmk:612: build-test-hotspot-jtreg-native] Error 2 This pull request has now been integrated. Changeset: fb139cff Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/fb139cff Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8257467: [TESTBUG] -Wdeprecated-declarations is reported at sigset() in exesigtest.c Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1529 From ysuenaga at openjdk.java.net Wed Dec 2 09:22:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 09:22:55 GMT Subject: Integrated: 8256008: UL does not report anything if disk writing fails In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 07:19:09 GMT, Yasumasa Suenaga wrote: > If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. > > `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. > We should check them, and should report what happened if error occurred. > > > How to reproduce on Linux: > > 1. Mount tmpfs with 512K > > $ mkdir /tmp/tmp > $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp > > 2. Run `java` with `-Xlog` > > $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version This pull request has now been integrated. Changeset: 3e3745c2 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/3e3745c2 Stats: 56 lines in 3 files changed: 37 ins; 2 del; 17 mod 8256008: UL does not report anything if disk writing fails Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From stuefe at openjdk.java.net Wed Dec 2 10:54:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 10:54:03 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set Message-ID: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Hi, may I please have reviews for the following very small improvement: While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: size_t os::_page_sizes[os::page_sizes_max]; is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). That has the following advantages: - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. ----- The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. Testing: - nightlies at SAP - manual tests with UseLargePages - the new gtests - gh actions (with x86 still failing because of unrelated issues) Thank you, Thomas [1] https://bugs.openjdk.java.net/browse/JDK-8243315 [2] https://bugs.openjdk.java.net/browse/JDK-8256155 ------------- Commit messages: - Add PagesizeSet Changes: https://git.openjdk.java.net/jdk/pull/1522/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257588 Stats: 227 lines in 7 files changed: 174 ins; 30 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From rrich at openjdk.java.net Wed Dec 2 11:41:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 2 Dec 2020 11:41:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:34:09 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings >> >> Tested in our nightlies for a week now, works fine. >> >> Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Ioi Hi Thomas, I've got a few minor comments for you. Have you got a sample of the trace you could share in this PR? Thanks, Richard. src/hotspot/os/windows/os_windows.cpp line 3220: > 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, > 3219: RANGE_FORMAT_ARGS(base, size)); > 3220: os::print_memory_mappings((char*)base, size, tty); The type cast for `base` is redundant. src/hotspot/os/windows/os_windows.cpp line 3218: > 3216: (attempt_reserve_memory_at(split_address, size - split) != NULL); > 3217: if (!rc) { > 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, I'm not very much in favor of the closing ")". It will confuse editors trying to match brackets/parenthesis when reading logs. Also I think it is redundant because an inclusive end does not make much sense without specifying how many bytes are included at the end address. I see there are already uses of that style so I won't veto if you prefer to keep it. src/hotspot/os/windows/os_windows.cpp line 6074: > 6072: char buf[MAX_PATH]; > 6073: int dummy; > 6074: if (os::dll_address_to_library_name(allocation_base, buf, sizeof(buf), &dummy)) { You could pass nullptr instead of &dummy src/hotspot/os/windows/os_windows.cpp line 6001: > 5999: const int errval = 0xDE210244; > 6000: for (int i = 0; i < num_words; i++) { > 6001: v[i] = SafeFetch32((int*)p + i, errval); I think you will get a sign extend of the loaded 4 bytes to 8 bytes intptr_t on 64 bit. This will be confusing. What about using int[] for v and INTX_FORMAT for printing? Alternatively you could leave it like this and use SafeFetchN(). I'd think that would be best. src/hotspot/os/windows/os_windows.cpp line 6141: > 6139: // is large, this may take a long time. Therefore lets stop right away if the address > 6140: // is outside of what we know are valid addresses on Windows. Also, add a loop fuse. > 6141: static const address end_phys = (address)(LP64_ONLY(0x7ffffffffffULL) NOT_LP64(3*G)); This is a virtual address, right? So better name it end_virt? src/hotspot/os/windows/os_windows.cpp line 6108: > 6106: address end = start + bytes; > 6107: address p = start; > 6108: if (p == NULL) { // Lets skip the zero pages. According to hotspot-style.md nullptr should be preferred. src/hotspot/share/runtime/os.cpp line 1742: > 1740: // Prints all mappings > 1741: void os::print_memory_mappings(outputStream* st) { > 1742: os::print_memory_mappings(NULL, (size_t)-1, st); According to hotspot-style.md nullptr should be preferred. test/hotspot/gtest/runtime/test_os.cpp line 504: > 502: buf[0] = '\0'; > 503: stringStream ss(buf, buflen); > 504: if (start != NULL) { According to hotspot-style.md nullptr should be preferred. test/hotspot/gtest/runtime/test_os.cpp line 523: > 521: > 522: TEST_VM(os, show_mappings_full_range) { > 523: test_show_mappings(NULL, 0); According to hotspot-style.md nullptr should be preferred. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:25:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:25:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: <2BOQW8WbRGtejblDy_jz1DwhI2hi-Td6ZVdGPb1VwZQ=.bf6b2f75-2ced-494c-9fc5-bff41f21dce2@github.com> On Wed, 2 Dec 2020 11:38:29 GMT, Richard Reingruber wrote: > Hi Thomas, > > I've got a few minor comments for you. > > Have you got a sample of the trace you could share in this PR? > > Thanks, Richard. Yes, see link in the PR description. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:29:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:29:59 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: <3F0jAXa5fJz16qWOMgcI31Yr3A4fmtawA3v7G3-lRZ0=.72c8b39b-7948-431d-abbf-859c1aed066d@github.com> On Wed, 2 Dec 2020 08:50:49 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > src/hotspot/os/windows/os_windows.cpp line 3218: > >> 3216: (attempt_reserve_memory_at(split_address, size - split) != NULL); >> 3217: if (!rc) { >> 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, > > I'm not very much in favor of the closing ")". It will confuse editors trying to match brackets/parenthesis when reading logs. Also I think it is redundant because an inclusive end does not make much sense without specifying how many bytes are included at the end address. > > I see there are already uses of that style so I won't veto if you prefer to keep it. Okay, I agree. Good point with the editors. Exclusive end is the usual default anyway. I'll rework this in a follow up if there is a follow up (there probably will be one). ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:47:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:47:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:25:13 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > src/hotspot/os/windows/os_windows.cpp line 6001: > >> 5999: const int errval = 0xDE210244; >> 6000: for (int i = 0; i < num_words; i++) { >> 6001: v[i] = SafeFetch32((int*)p + i, errval); > > I think you will get a sign extend of the loaded 4 bytes to 8 bytes intptr_t on 64 bit. This will be confusing. What about using int[] for v and INTX_FORMAT for printing? > Alternatively you could leave it like this and use SafeFetchN(). I'd think that would be best. Oh this is a stupid mistake. I alternated several times between SafeFetchN and SafeFetch32. I must have committed an inconsistent version. Good catch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:51:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:51:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:38:07 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > test/hotspot/gtest/runtime/test_os.cpp line 523: > >> 521: >> 522: TEST_VM(os, show_mappings_full_range) { >> 523: test_show_mappings(NULL, 0); > > According to hotspot-style.md nullptr should be preferred. Sigh. I have an unreasonable dislike against nullptr and the churn that causes (NULL is nullptr anyway post C++11). But I'll be a good boy and change all those :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 13:50:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 13:50:11 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v6] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Richard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/de705074..89b59069 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=04-05 Stats: 22 lines in 3 files changed: 11 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 13:52:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 13:52:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:38:29 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > Hi Thomas, > > I've got a few minor comments for you. > > Have you got a sample of the trace you could share in this PR? > > Thanks, Richard. Hi @reinrich thanks a lot for your review. Please take a look at the new version. I modified the test to create a test mapping, just for showing that the snippets are printed out okay. See below, 64- and 32-bit-versions (look for "ABCD" to find the mapping). [printout-32.txt](https://github.com/openjdk/jdk/files/5629650/printout-32.txt) [printout-64.txt](https://github.com/openjdk/jdk/files/5629651/printout-64.txt) Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From rrich at openjdk.java.net Wed Dec 2 14:08:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 2 Dec 2020 14:08:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v6] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 13:50:11 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings >> >> Tested in our nightlies for a week now, works fine. >> >> Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Richard LGTM, thanks :) src/hotspot/os/windows/os_windows.cpp line 6073: > 6071: if (first_line) { > 6072: char buf[MAX_PATH]; > 6073: if (os::dll_address_to_library_name(allocation_base, buf, sizeof(buf), NULL)) { You forgot one NULL ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 14:32:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 14:32:13 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v7] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: the last NULL is null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/89b59069..bed9505e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From dcubed at openjdk.java.net Wed Dec 2 15:13:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Dec 2020 15:13:58 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 22:39:08 GMT, David Holmes wrote: >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore volatile modifier Sorry for the late review. Looks good to me. The only thing that I noticed was you went with a "raw_" prefix with your raw_set_owner() and I went with a "_raw" suffix with my ObjectMonitor::owner_raw(). Nothing wrong with either, but the difference stood out. ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From minqi at openjdk.java.net Wed Dec 2 16:20:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 2 Dec 2020 16:20:57 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v5] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 2 Dec 2020 06:54:08 GMT, Thomas Stuefe wrote: > Looks good. Thank you for your perseverance. > Cheers, Thomas Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From minqi at openjdk.java.net Wed Dec 2 16:25:58 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 2 Dec 2020 16:25:58 GMT Subject: Integrated: 8256256: UL should not use heap allocation for output string In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 03:04:07 GMT, Yumin Qi wrote: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 This pull request has now been integrated. Changeset: 0b8c7807 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/0b8c7807 Stats: 40 lines in 1 file changed: 29 ins; 0 del; 11 mod 8256256: UL should not use heap allocation for output string Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From mchung at openjdk.java.net Wed Dec 2 16:58:59 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Dec 2020 16:58:59 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v4] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 01:12:17 GMT, Calvin Cheung wrote: >> Please review this change which includes: >> >> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. >> >> - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. >> >> Testing: >> >> - [x] all cds/appcds tests locally on linux-x64 >> >> - [x] tiers 1 - 4 (in progress) > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > 1. Update comment block in LambdaEagerInitTest.java > 2. Add more test cases using the default CDS archive in LambdaEagerInit.java Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From hseigel at openjdk.java.net Wed Dec 2 18:44:08 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:44:08 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/84e421f7..2c5bec9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01-02 Stats: 40 lines in 2 files changed: 3 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:54:03 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:54:03 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:02:57 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 617: > >> 615: #ifndef PRODUCT >> 616: // These options are removed in jdk9. Remove this code for jdk10. >> 617: static AliasedFlag const removed_develop_logging_flags[] = { > > I think this removed_develop_logging_flags infrastructure should be removed. done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:53:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:53:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: <4H1k-dufXhXpZM-wIl6YTa4b8_6SGcOWOC6QG4LXXf0=.f54a8f80-b42a-4392-8c8e-88bd2b2c308e@github.com> On Wed, 2 Dec 2020 02:42:18 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I'm still pushing for treating all flags the same and removing all the aliased-flag code. > > Coleen seems to be okay either way. :) > > Thanks, > David Please review this latest webrev. It removes all the aliasing code for the obsolete tracing flags and does not suggest logging alternatives in their obsolete flag messages. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From sspitsyn at openjdk.java.net Wed Dec 2 19:30:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 19:30:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags The update looks good to me. It is a nice simplification. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From iklam at openjdk.java.net Wed Dec 2 21:13:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 21:13:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From ccheung at openjdk.java.net Wed Dec 2 22:10:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 22:10:13 GMT Subject: RFR: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes [v5] In-Reply-To: References: Message-ID: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: Skip testing with default CDS archive on aarch64 platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1542/files - new: https://git.openjdk.java.net/jdk/pull/1542/files/fc10e77f..ec851f0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1542&range=03-04 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1542/head:pull/1542 PR: https://git.openjdk.java.net/jdk/pull/1542 From ccheung at openjdk.java.net Wed Dec 2 22:21:02 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 2 Dec 2020 22:21:02 GMT Subject: Integrated: 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote: > Please review this change which includes: > > - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy classes or to find them from an archive. > > - Not passing the `initialize` (same as `!disableEagerInitialization`) to `LambdaProxyClassArchive.find` and eventually to the `JVM_LookupLambdaProxyClassFromArchive` function. > > Testing: > > - [x] all cds/appcds tests locally on linux-x64 > > - [x] tiers 1 - 4 (in progress) This pull request has now been integrated. Changeset: 3da30e99 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/3da30e99 Stats: 193 lines in 9 files changed: 135 ins; 16 del; 42 mod 8257241: CDS should not handle disableEagerInitialization for archived lambda proxy classes Reviewed-by: iklam, redestad, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/1542 From dholmes at openjdk.java.net Wed Dec 2 23:02:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 23:02:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Thu Dec 3 00:06:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 3 Dec 2020 00:06:03 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale [v2] In-Reply-To: <_Zpz_-LWLOzOmBqTkqjcUKLSTKCn7GveBpuSrn830No=.b7bb5d20-f428-4751-b285-03811726dd76@github.com> References: <_Zpz_-LWLOzOmBqTkqjcUKLSTKCn7GveBpuSrn830No=.b7bb5d20-f428-4751-b285-03811726dd76@github.com> Message-ID: On Fri, 27 Nov 2020 06:35:16 GMT, Thomas Stuefe wrote: >> The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. >> >> Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. >> >> Background: >> >> The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. >> >> This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. >> >> That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. >> >> But it messes up statistics a bit. Example: >> >> jcmd xxx VM.metaspace >> >> >> >> Chunk freelists: >> >> Both: >> >> 4m: (none) >> 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) >> 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) >> 512k: (none) >> 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) >> 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) >> 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) >> 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed >> 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too >> 8k: (none) >> 4k: (none) >> 2k: (none) >> 1k: (none) >> Total word size: 5,83 MB, committed: 0 bytes ( 0%) >> >> >> In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. >> >> The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: >> >> Both: >> >> 4m: (none) >> 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) >> 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) >> 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) >> 256k: (none) >> 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) >> 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) >> 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good >> 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good >> 8k: (none) >> 4k: (none) >> 2k: (none) >> 1k: (none) >> Total word size: 8,78 MB, committed: 96,00 KB ( 1%) >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - Add gtest for Vsn::is_range_fully_committed > - Initial src/hotspot/share/memory/metaspace/metachunk.cpp line 185: > 183: for (Metachunk* c = prev_in_vs(); c != NULL && c->base() >= granule_start; c = c->prev_in_vs()) { > 184: assert(c->committed_words() == 0, "neighbor was already committed?"); > 185: c->_committed_words = c->word_size(); Can the previous metachunk be partially contained in the commit granule? ie c->base < granule_start but c->end >= granule start? ------------- PR: https://git.openjdk.java.net/jdk/pull/1291 From dholmes at openjdk.java.net Thu Dec 3 04:41:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 3 Dec 2020 04:41:01 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Message-ID: The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. A CSR request has been filed. Testing: hotspot/jtreg/runtime/signal tests Thanks, David ------------- Commit messages: - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Changes: https://git.openjdk.java.net/jdk/pull/1587/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1587&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257572 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1587.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1587/head:pull/1587 PR: https://git.openjdk.java.net/jdk/pull/1587 From stuefe at openjdk.java.net Thu Dec 3 08:40:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:40:17 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix 32bit issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/7014f81e..9e936bcf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=00-01 Stats: 95 lines in 2 files changed: 39 ins; 29 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 08:44:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:44:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:37:18 GMT, Ioi Lam wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > Marked as reviewed by iklam (Reviewer). Thanks @iklam and @reinrich . All tests went through sucessfully tonight. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Thu Dec 3 08:44:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:44:57 GMT Subject: Integrated: JDK-8256864: [windows] Improve tracing for mapping errors In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:26:45 GMT, Thomas Stuefe wrote: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt This pull request has now been integrated. Changeset: b44a329f Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/b44a329f Stats: 143 lines in 4 files changed: 123 ins; 2 del; 18 mod 8256864: [windows] Improve tracing for mapping errors Reviewed-by: iklam, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From rrich at openjdk.java.net Thu Dec 3 08:52:56 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 3 Dec 2020 08:52:56 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails [v2] In-Reply-To: <7GcPQHwIFlxySeW8TRXBVKNLC9-qSDgW-PHfeC7O8QU=.e510674b-51bb-4f31-a0c7-b73f49376ae4@github.com> References: <7GcPQHwIFlxySeW8TRXBVKNLC9-qSDgW-PHfeC7O8QU=.e510674b-51bb-4f31-a0c7-b73f49376ae4@github.com> Message-ID: On Tue, 1 Dec 2020 14:08:14 GMT, Thomas Stuefe wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Special case for AIX in largeHeapTest(). > > small nits; leave it up to you if you follow up on them. > LGTM otherwise. > Also, (T)rivial :) Testing succeeded. Thanks again for the reviews @tstuefe and @TheRealMDoerr. ------------- PR: https://git.openjdk.java.net/jdk/pull/1512 From rrich at openjdk.java.net Thu Dec 3 08:52:57 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 3 Dec 2020 08:52:57 GMT Subject: Integrated: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: References: Message-ID: <9BgJNPqWlwWJPXzNe-ShjRpXzzH6eWeEVxD62suIGro=.673465a7-2bf9-4af8-886e-05adabf3605f@github.com> On Mon, 30 Nov 2020 09:01:20 GMT, Richard Reingruber wrote: > This is an XS sized patch to get a zerobased compressed class space on > Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. > > On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one > attempt is made to place the CCS right after the heap which will be at 4g > (ELF_ET_DYN_BASE) but there the java launcher is already mapped. > > This change reuses the search already implemented for AARCH64. > > Master without Fix Master with Fix > > -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space > ---------------------------------------------------------------------------------------------------- > 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 > 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 > 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 > 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 > 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 This pull request has now been integrated. Changeset: 4a267f1b Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/4a267f1b Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Reviewed-by: stuefe, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/1512 From tschatzl at openjdk.java.net Thu Dec 3 10:23:02 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 10:23:02 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 08:40:17 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix 32bit issues Changes requested by tschatzl (Reviewer). To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P src/hotspot/share/runtime/os.cpp line 79: > 77: int os::_processor_count = 0; > 78: int os::_initial_active_processor_count = 0; > 79: os::PagesizeSet os::_page_sizes; While I'm typically not a fan of aligning variable identifiers, it's already there. Please align this new one too with the others. src/hotspot/share/runtime/os.cpp line 1851: > 1849: > 1850: ////// Implementation of pagesizeset_t > 1851: There is no pagesizeset_t ;) src/hotspot/share/runtime/os.cpp line 1854: > 1852: // A pagesizeset_t is a set containing a set of page sizes. > 1853: > 1854: // sets the given page size Not sure if this is the correct place for a description what the method does, it seems to me that the definition in the hpp file is a better place. Also all other methods are described there already, and this description does not add anything new. src/hotspot/share/runtime/os.cpp line 1863: > 1861: bool os::PagesizeSet::is_set(size_t pagesize) const { > 1862: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1863: return _v & pagesize; Please do not rely on implicit comparison against unequal 0. src/hotspot/share/runtime/os.cpp line 1870: > 1868: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1869: // mask out all pages sizes >= pagesize: > 1870: uintx v2 = _v & pagesize - 1; I would prefer to add the brackets instead of relying on operator strengths. They would make the intent more clear or at least require less thinking. src/hotspot/share/runtime/os.cpp line 1904: > 1902: size_t os::PagesizeSet::smallest() const { > 1903: assert(min_page_size() > 0, "Sanity"); > 1904: return next_larger(min_page_size() / 2); Why not just return `min_page_size()` here? An assert may be added to check that they are the same though. src/hotspot/share/runtime/os.hpp line 103: > 101: > 102: public: > 103: The class PagesizeSet does not need to be public. src/hotspot/share/runtime/os.cpp line 1860: > 1858: } > 1859: > 1860: // returns true if given page size is part of the set Same as for `add()`. src/hotspot/share/runtime/os.hpp line 112: > 110: bool is_set(size_t pagesize) const; > 111: // given a page size, return the next smaller page size in this set, or 0. > 112: size_t next_smaller(size_t pagesize) const; Please let all documentation sentences start with upper case. src/hotspot/share/runtime/os.cpp line 1919: > 1917: } else if (sz < G) { > 1918: st->print(SIZE_FORMAT "m", sz / M); > 1919: } else { The prefixes for mega/gigabyte are "M" and "G" instead of "m" and "g" respectively src/hotspot/share/runtime/os.cpp line 1887: > 1885: return 0; > 1886: } > 1887: while ((v2 & 1) == 0) { Maybe the `count_trailing_zeros()` method could be used here instead of doing the same manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522Changes requested by tschatzl (Reviewer). From jiefu at openjdk.java.net Thu Dec 3 11:15:15 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 3 Dec 2020 11:15:15 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: References: Message-ID: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 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 five additional commits since the last revision: - Merge branch 'master' into JDK-8257230 - Refinement & jtreg test - Merge branch 'master' into JDK-8257230 - Merge branch 'master' into JDK-8257230 - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1492/files - new: https://git.openjdk.java.net/jdk/pull/1492/files/0389bc4d..92208d48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=01-02 Stats: 10006 lines in 347 files changed: 7909 ins; 1033 del; 1064 mod Patch: https://git.openjdk.java.net/jdk/pull/1492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492 PR: https://git.openjdk.java.net/jdk/pull/1492 From ihse at openjdk.java.net Thu Dec 3 11:19:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 3 Dec 2020 11:19:57 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David As we say in Swedish: ?ntligen! :-) Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587 From alanb at openjdk.java.net Thu Dec 3 11:26:55 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 3 Dec 2020 11:26:55 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From david.holmes at oracle.com Thu Dec 3 11:29:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2020 21:29:39 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On 3/12/2020 9:19 pm, Magnus Ihse Bursie wrote: > On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > >> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >> >> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >> >> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >> >> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >> >> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > As we say in Swedish: ?ntligen! :-) > > Build changes look good. Thanks for the review Magnus! David ----- > ------------- > > Marked as reviewed by ihse (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1587 > From david.holmes at oracle.com Thu Dec 3 11:30:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Dec 2020 21:30:14 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On 3/12/2020 9:26 pm, Alan Bateman wrote: > On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > >> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >> >> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >> >> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >> >> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >> >> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > Marked as reviewed by alanb (Reviewer). Thanks for the Review Alan! David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1587 > From stuefe at openjdk.java.net Thu Dec 3 12:16:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 12:16:57 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:49:14 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.cpp line 1904: > >> 1902: size_t os::PagesizeSet::smallest() const { >> 1903: assert(min_page_size() > 0, "Sanity"); >> 1904: return next_larger(min_page_size() / 2); > > Why not just return `min_page_size()` here? > > An assert may be added to check that they are the same though. Not sure what you mean. PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 12:23:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 12:23:59 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale [v2] In-Reply-To: References: <_Zpz_-LWLOzOmBqTkqjcUKLSTKCn7GveBpuSrn830No=.b7bb5d20-f428-4751-b285-03811726dd76@github.com> Message-ID: On Thu, 3 Dec 2020 00:02:50 GMT, Coleen Phillimore wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge >> - Add gtest for Vsn::is_range_fully_committed >> - Initial > > src/hotspot/share/memory/metaspace/metachunk.cpp line 185: > >> 183: for (Metachunk* c = prev_in_vs(); c != NULL && c->base() >= granule_start; c = c->prev_in_vs()) { >> 184: assert(c->committed_words() == 0, "neighbor was already committed?"); >> 185: c->_committed_words = c->word_size(); > > Can the previous metachunk be partially contained in the commit granule? ie c->base < granule_start but c->end >= granule start? No. A chunk smaller than a granule is fully contained in one granule; a chunk larger than a granule contains only full granules. Which is inbuilt since both chunks and granules are pow2 values, and start at addresses aligned to their size. But just to make things very explicit I'll add an assert for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1291 From tschatzl at openjdk.java.net Thu Dec 3 12:28:55 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 12:28:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 12:13:53 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1904: >> >>> 1902: size_t os::PagesizeSet::smallest() const { >>> 1903: assert(min_page_size() > 0, "Sanity"); >>> 1904: return next_larger(min_page_size() / 2); >> >> Why not just return `min_page_size()` here? >> >> An assert may be added to check that they are the same though. > > Not sure what you mean. > > PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. > > os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. > > The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). Okay, apologies for falling into the mentioned trap. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 12:33:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 12:33:14 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 13:33:33 GMT, Thomas Stuefe wrote: > The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. > > Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. > > Background: > > The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. > > This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. > > That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. > > But it messes up statistics a bit. Example: > > jcmd xxx VM.metaspace > > > > Chunk freelists: > > Both: > > 4m: (none) > 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) > 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) > 512k: (none) > 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed > 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 5,83 MB, committed: 0 bytes ( 0%) > > > In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. > > The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: > > Both: > > 4m: (none) > 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) > 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) > 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) > 256k: (none) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good > 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 8,78 MB, committed: 96,00 KB ( 1%) > > Thanks, Thomas Note: I decided to move this fix up to JDK17. The fix is fine and simple, but since Elastic Metaspace was itself a large patch - which is well tested now - I'd like to minimize any unnecessary changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1291 From stuefe at openjdk.java.net Thu Dec 3 12:33:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 12:33:13 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale [v3] In-Reply-To: References: Message-ID: <_Z99ck2Kn6jLmEMkMb27nI7wRIcHLbBKNPA42KGxQAI=.edad831f-6b3e-428f-9da9-3134a843e7ef@github.com> > The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. > > Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. > > Background: > > The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. > > This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. > > That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. > > But it messes up statistics a bit. Example: > > jcmd xxx VM.metaspace > > > > Chunk freelists: > > Both: > > 4m: (none) > 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) > 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) > 512k: (none) > 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed > 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 5,83 MB, committed: 0 bytes ( 0%) > > > In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. > > The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: > > Both: > > 4m: (none) > 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) > 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) > 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) > 256k: (none) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good > 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 8,78 MB, committed: 96,00 KB ( 1%) > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Add an assert to make chunk-to-granule-geometry explicit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1291/files - new: https://git.openjdk.java.net/jdk/pull/1291/files/037d3b2e..205425e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=01-02 Stats: 27 lines in 3 files changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1291/head:pull/1291 PR: https://git.openjdk.java.net/jdk/pull/1291 From jiefu at openjdk.java.net Thu Dec 3 12:35:00 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 3 Dec 2020 12:35:00 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> References: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> Message-ID: On Mon, 30 Nov 2020 13:42:56 GMT, Thomas Schatzl 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 five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8257230 >> - Refinement & jtreg test >> - Merge branch 'master' into JDK-8257230 >> - Merge branch 'master' into JDK-8257230 >> - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes > > I think the change is good, but please add a test for this. > > E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. Hi @tschatzl and @kstefanj , could you help to review this change? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Thu Dec 3 12:57:02 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 3 Dec 2020 12:57:02 GMT Subject: RFR: 8257673: Build fails without shenandoahgc after JDK-8257563 Message-ID: Hi all, Please review this one-line change, which fixes the build failure without shenandoahgc. Testing: - Build tests without shenandoahgc and PCH on Linux/x64 Thanks. Best regards, Jie ------------- Commit messages: - 8257673: Build fails without shenandoahgc after JDK-8257563 Changes: https://git.openjdk.java.net/jdk/pull/1594/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1594&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257673 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1594.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1594/head:pull/1594 PR: https://git.openjdk.java.net/jdk/pull/1594 From stuefe at openjdk.java.net Thu Dec 3 13:01:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:01:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 12:26:04 GMT, Thomas Schatzl wrote: >> Not sure what you mean. >> >> PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. >> >> os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. >> >> The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). > > Okay, apologies for falling into the mentioned trap. No problem. We should probably improve this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 13:17:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:17:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:50:54 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.hpp line 103: > >> 101: >> 102: public: >> 103: > > The class PagesizeSet does not need to be public. Would it be okay to leave this public anyway? It is used from the gtests. I could make a fixture class and make it friend of os but that would be similarly ugly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From hseigel at openjdk.java.net Thu Dec 3 13:17:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:17:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 23:00:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > Looks good! > > Thanks, > David Thanks Coleen, Ioi, Serguei, and David for all the reviews. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Thu Dec 3 13:18:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:18:01 GMT Subject: Integrated: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold This pull request has now been integrated. Changeset: e4497c9e Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/e4497c9e Stats: 326 lines in 23 files changed: 16 ins; 289 del; 21 mod 8256718: Obsolete the long term deprecated and aliased Trace flags Reviewed-by: sspitsyn, iklam, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From stuefe at openjdk.java.net Thu Dec 3 13:26:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:26:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:59:16 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.cpp line 1860: > >> 1858: } >> 1859: >> 1860: // returns true if given page size is part of the set > > Same as for `add()`. Not possible, since its used from within os::Linux, os::Aix etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From aph at openjdk.java.net Thu Dec 3 13:34:57 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 3 Dec 2020 13:34:57 GMT Subject: RFR: 8257673: Build fails without shenandoahgc after JDK-8257563 In-Reply-To: References: Message-ID: <2mO9PvkGAX7BsJStnjNK4jIWlyF-gOcPQ1AEkY5HR9w=.81ce32f5-05f7-4a6e-974e-610c8785e6f9@github.com> On Thu, 3 Dec 2020 12:51:42 GMT, Jie Fu wrote: > Hi all, > > Please review this one-line change, which fixes the build failure without shenandoahgc. > > Testing: > - Build tests without shenandoahgc and PCH on Linux/x64 > > Thanks. > Best regards, > Jie Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1594 From tschatzl at openjdk.java.net Thu Dec 3 13:42:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 13:42:58 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:23:41 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1860: >> >>> 1858: } >>> 1859: >>> 1860: // returns true if given page size is part of the set >> >> Same as for `add()`. > > Not possible, since its used from within os::Linux, os::Aix etc. Your comment is probably related to the comment of making the `PageSizeSet` class private. Hmm, I did try that out though and compiled locally on Linux.... maybe I messed up somewhere. Leave it public then. Otherwise I am a bit confused how this statement relates to the request to move the code comment to the .hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From sjohanss at openjdk.java.net Thu Dec 3 13:50:00 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 3 Dec 2020 13:50:00 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: References: Message-ID: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> On Thu, 3 Dec 2020 11:15:15 GMT, Jie Fu wrote: >> Hi all, >> >> Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. >> For example, this assert [1] fired on our testing boxes. >> >> It can be reproduced by the following two steps on Linux-64: >> 1) ulimit -v 8388608 >> 2) java -XX:MinHeapSize=5g -version >> The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. >> >> One more important fact is that this bug can be more common on Linux-32 systems. >> Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. >> >> Testing: >> - tier1 ~ tier3 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8257230 > - Refinement & jtreg test > - Merge branch 'master' into JDK-8257230 > - Merge branch 'master' into JDK-8257230 > - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes Took a closer look at the test now, some comment below. test/hotspot/jtreg/gc/ergonomics/TestMinHeapSize.java line 33: > 31: * > 32: * @comment Not run on AIX as it does not support ulimit -v > 33: * @requires os.family != "aix" I would change this to only be run on Linux: * @requires os.family == "linux" test/hotspot/jtreg/gc/ergonomics/TestMinHeapSize.java line 46: > 44: String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm( > 45: "-XX:MinHeapSize=" + "260m", "-version")); > 46: cmd = escapeCmd(cmd); If we change to only run on Linux, this is not needed. test/hotspot/jtreg/gc/ergonomics/TestMinHeapSize.java line 45: > 43: public static void main(String[] args) throws Throwable { > 44: String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm( > 45: "-XX:MinHeapSize=" + "260m", "-version")); `createTestJvm()` will pick up additional options passed by the test runner and there might be conflicting options. So I would suggest not picking up any additional options. test/hotspot/jtreg/gc/ergonomics/TestMinHeapSize.java line 59: > 57: > 58: oa.shouldNotContain("hs_err") > 59: .shouldNotContain("Internal Error"); Should it also check that the exit status is ok, or can't we expect that for sure? ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1492 From stuefe at openjdk.java.net Thu Dec 3 13:53:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:53:56 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:39:47 GMT, Thomas Schatzl wrote: >> Not possible, since its used from within os::Linux, os::Aix etc. > > Your comment is probably related to the comment of making the `PageSizeSet` class private. Hmm, I did try that out though and compiled locally on Linux.... maybe I messed up somewhere. Leave it public then. > > Otherwise I am a bit confused how this statement relates to the request to move the code comment to the .hpp file. You know, communication was a bit easier when we wrote mails :) I thought you meant "make add() private". Sorry for my confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 13:59:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:59:11 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Thomas ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/9e936bcf..fdae7642 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=01-02 Stats: 24 lines in 3 files changed: 2 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 13:59:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:59:12 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 10:20:01 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P Hi Thomas, thanks again for the review. I hope I addressed all points. I completely removed the comments from the cpp file and corrected them in the hpp file, which removes the need to keep them in sync. And I rather have them in the hpp file, that makes my IDE happy. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From erikj at openjdk.java.net Thu Dec 3 14:07:01 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Dec 2020 14:07:01 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David make/modules/java.base/Lib.gmk line 131: > 129: ifeq ($(call isTargetOsType, unix), true) > 130: ifeq ($(STATIC_BUILD), false) > 131: LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"' In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From dcubed at openjdk.java.net Thu Dec 3 14:42:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 3 Dec 2020 14:42:58 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Thumbs up on the jsig.c change. No comment on the Lib.gmk change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1587 From shade at openjdk.java.net Thu Dec 3 17:20:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 17:20:03 GMT Subject: RFR: 8257673: Build fails without shenandoahgc after JDK-8257563 In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:51:42 GMT, Jie Fu wrote: > Hi all, > > Please review this one-line change, which fixes the build failure without shenandoahgc. > > Testing: > - Build tests without shenandoahgc and PCH on Linux/x64 > > Thanks. > Best regards, > Jie Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1594 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 17:57:56 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 17:57:56 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:56:03 GMT, Thomas Stuefe wrote: >> To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P > > Hi Thomas, > > thanks again for the review. I hope I addressed all points. I completely removed the comments from the cpp file and corrected them in the hpp file, which removes the need to keep them in sync. And I rather have them in the hpp file, that makes my IDE happy. > > Cheers, Thomas +1 on the general thrust of this change. I'd be happy to incorporate into https://github.com/openjdk/jdk/pull/1153 & JDK-8256155 [1] if they are approved. [1] https://bugs.openjdk.java.net/browse/JDK-8256155 ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From richard.reingruber at sap.com Thu Dec 3 20:07:50 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 3 Dec 2020 20:07:50 +0000 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: Hi Thomas, patch looks good to me. You might want to remove the extraneous whitespace between the ++ operator and its operand in the line below. 3086 for (int attempt = 0; attempt < max_attempts && aligned_base == NULL; attempt ++) { Thanks, Richard. -----Original Message----- From: jdk-updates-dev On Behalf Of Thomas St?fe Sent: Mittwoch, 2. Dezember 2020 09:31 To: jdk-updates-dev Cc: Hotspot dev runtime Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Hi, I'd like to get reviews for the backport of the following fix: Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Original patch: https://github.com/openjdk/jdk/commit/0357db35 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff This patch had to be rewritten for 11 since most of the surroundings changed since 11 due to cleanups. But the patch itself is straightforward. Thank you, Thomas From thomas.stuefe at gmail.com Thu Dec 3 20:26:59 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Dec 2020 21:26:59 +0100 Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: Thank you Richard. Will do. .:Thomas On Thu, Dec 3, 2020 at 9:07 PM Reingruber, Richard < richard.reingruber at sap.com> wrote: > Hi Thomas, > > patch looks good to me. > > You might want to remove the extraneous whitespace between the ++ operator > and > its operand in the line below. > > 3086 for (int attempt = 0; attempt < max_attempts && aligned_base == > NULL; attempt ++) { > > Thanks, Richard. > > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Thomas St?fe > Sent: Mittwoch, 2. Dezember 2020 09:31 > To: jdk-updates-dev > Cc: Hotspot dev runtime > Subject: [11u] RFR: JDK-8256287: [windows] add loop fuse to > map_or_reserve_memory_aligned > > Hi, > > I'd like to get reviews for the backport of the following fix: > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8256287 > Original patch: https://github.com/openjdk/jdk/commit/0357db35 > Modified patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8256287-windows-add-loop-fuse-to-map_or_reserve_memory_aligned-for-11.diff > > This patch had to be rewritten for 11 since most of the surroundings > changed since 11 due to cleanups. But the patch itself is straightforward. > > Thank you, Thomas > From stefank at openjdk.java.net Thu Dec 3 21:17:59 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 3 Dec 2020 21:17:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 13:59:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Thomas Just a few drive-by comment: Could PagesizeSet be named PageSizeSet. The rest of the code separates the word, so I think that name would be better. The same for some of the parameters that are named pagesize. Also, I think you could have called the class PageSizes. I don't think the fact that this is a 'set' matters for the usages of the class. It also makes the variable name match the type name, which I guess is an indication that it wouldn't be such a bad name: ``` static PageSizes _page_sizes;` vs static PagesizeSet _page_sizes; ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Thu Dec 3 21:28:59 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 3 Dec 2020 21:28:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 13:59:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Thomas src/hotspot/share/runtime/os.cpp line 1859: > 1857: bool os::PagesizeSet::is_set(size_t pagesize) const { > 1858: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1859: return (_v & pagesize) > 0; Why is this `> 0` and not simply `!= 0` src/hotspot/share/runtime/os.cpp line 1869: > 1867: return round_down_power_of_2(v2); > 1868: } > 1869: return 0; In next_larger you use the for: if (v2 == 0) { return 0; } return ... I think it would be nice to be consistent between the two functions. src/hotspot/share/runtime/os.cpp line 1863: > 1861: > 1862: size_t os::PagesizeSet::next_smaller(size_t pagesize) const { > 1863: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); You're using INTPR_FORMAT to print a size_t. I guess this is done to print hex values. We have a SIZE_FORMAT_HEX for that use case. src/hotspot/share/runtime/os.hpp line 110: > 108: PagesizeSet() : _v(0) {} > 109: void add(size_t pagesize); > 110: bool is_set(size_t pagesize) const; Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? src/hotspot/share/runtime/os.hpp line 106: > 104: // A simple value class holding a set of page sizes (similar to sigset_t) > 105: class PagesizeSet { > 106: uintx _v; All in-parameters are size_t. It seems like this could be size_t as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 22:59:06 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 22:59:06 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:23:46 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.hpp line 110: > >> 108: PagesizeSet() : _v(0) {} >> 109: void add(size_t pagesize); >> 110: bool is_set(size_t pagesize) const; > > Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? I'd prefer if this stays public, I've already found it useful, but I agree that the name could be more informative. Perhaps contains(size_t pagesize)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From jiefu at openjdk.java.net Thu Dec 3 23:11:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 3 Dec 2020 23:11:56 GMT Subject: RFR: 8257673: Build fails without shenandoahgc after JDK-8257563 In-Reply-To: <2mO9PvkGAX7BsJStnjNK4jIWlyF-gOcPQ1AEkY5HR9w=.81ce32f5-05f7-4a6e-974e-610c8785e6f9@github.com> References: <2mO9PvkGAX7BsJStnjNK4jIWlyF-gOcPQ1AEkY5HR9w=.81ce32f5-05f7-4a6e-974e-610c8785e6f9@github.com> Message-ID: On Thu, 3 Dec 2020 13:31:47 GMT, Andrew Haley wrote: >> Hi all, >> >> Please review this one-line change, which fixes the build failure without shenandoahgc. >> >> Testing: >> - Build tests without shenandoahgc and PCH on Linux/x64 >> >> Thanks. >> Best regards, >> Jie > > Marked as reviewed by aph (Reviewer). Thanks @theRealAph and @shipilev for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1594 From jiefu at openjdk.java.net Thu Dec 3 23:11:58 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 3 Dec 2020 23:11:58 GMT Subject: Integrated: 8257673: Build fails without shenandoahgc after JDK-8257563 In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:51:42 GMT, Jie Fu wrote: > Hi all, > > Please review this one-line change, which fixes the build failure without shenandoahgc. > > Testing: > - Build tests without shenandoahgc and PCH on Linux/x64 > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 37c7835c Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/37c7835c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8257673: Build fails without shenandoahgc after JDK-8257563 Reviewed-by: aph, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1594 From mseledtsov at openjdk.java.net Fri Dec 4 00:00:02 2020 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 4 Dec 2020 00:00:02 GMT Subject: RFR: JDK-8257732: Add TestJFRWithJMX.java to problem list for OL 8.2 until the issue =?UTF-8?B?aXPigKY=?= Message-ID: Problem list TestJFRWithJMX for OL 8.2 until the issue is resolved. ------------- Commit messages: - Add TestJFRWithJMX.java to problem list for OL 8.2 until the issue is resolved Changes: https://git.openjdk.java.net/jdk/pull/1612/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1612&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257732 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1612.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1612/head:pull/1612 PR: https://git.openjdk.java.net/jdk/pull/1612 From ccheung at openjdk.java.net Fri Dec 4 02:28:02 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 4 Dec 2020 02:28:02 GMT Subject: RFR: 8257651: LambdaEagerInit.java test failed in 2 different ways Message-ID: Please review this simple change for fixing the 2 issues as described in the bug report. - exclude the test from the hotspot_appcds_dynamic test group. - compile Asserts.java so that the class file will be located under the following dir `.../JTwork/classes/.../runtime/cds/appcds/LambdaEagerInit.d/jdk/test/lib/` Passed hs-tier4 tests. ------------- Commit messages: - 8257651: LambdaEagerInit.java test failed in 2 different ways Changes: https://git.openjdk.java.net/jdk/pull/1616/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257651 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1616.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1616/head:pull/1616 PR: https://git.openjdk.java.net/jdk/pull/1616 From jiefu at openjdk.java.net Fri Dec 4 03:57:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 4 Dec 2020 03:57:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v4] In-Reply-To: References: Message-ID: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 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 eight additional commits since the last revision: - Don't check the exit value - Update the test - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8257230 - Merge branch 'master' into JDK-8257230 - Refinement & jtreg test - Merge branch 'master' into JDK-8257230 - Merge branch 'master' into JDK-8257230 - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1492/files - new: https://git.openjdk.java.net/jdk/pull/1492/files/92208d48..2c6ff74c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=02-03 Stats: 1035 lines in 91 files changed: 566 ins; 345 del; 124 mod Patch: https://git.openjdk.java.net/jdk/pull/1492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492 PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Fri Dec 4 04:11:57 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 4 Dec 2020 04:11:57 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> References: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> Message-ID: On Thu, 3 Dec 2020 13:47:23 GMT, Stefan Johansson 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 five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8257230 >> - Refinement & jtreg test >> - Merge branch 'master' into JDK-8257230 >> - Merge branch 'master' into JDK-8257230 >> - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes > > Took a closer look at the test now, some comment below. Hi @kstefanj , Thanks for your review. The fix has been updated according to your comments. I don't check the exit value because I found different platforms may return different values (Zero on MacOS, but non-zero on Linux). Maybe, It should return 0 on Linux too, which I think is more reasonable. And I'd like to file another bug to fix it in the future. Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From stuefe at openjdk.java.net Fri Dec 4 05:35:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 05:35:03 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 22:56:04 GMT, Marcus G K Williams wrote: >> src/hotspot/share/runtime/os.hpp line 110: >> >>> 108: PagesizeSet() : _v(0) {} >>> 109: void add(size_t pagesize); >>> 110: bool is_set(size_t pagesize) const; >> >> Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? > > I'd prefer if this stays public, I've already found it useful, but I agree that the name could be more informative. Perhaps contains(size_t pagesize)? Cannot be private since its used from other nested classes (os::Linux etc). But I can rename it to contains() ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 05:39:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 05:39:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:25:28 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.hpp line 106: > >> 104: // A simple value class holding a set of page sizes (similar to sigset_t) >> 105: class PagesizeSet { >> 106: uintx _v; > > All in-parameters are size_t. It seems like this could be size_t as well. This is my personal taste; I dislike keeping anything a size_t which is not a memory range size (e.g. I dislike its use as an array index). But it does not matter much to me here since size_t is guaranteed to be unsigned. > src/hotspot/share/runtime/os.cpp line 1863: > >> 1861: >> 1862: size_t os::PagesizeSet::next_smaller(size_t pagesize) const { >> 1863: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > > You're using INTPR_FORMAT to print a size_t. I guess this is done to print hex values. We have a SIZE_FORMAT_HEX for that use case. Sure ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 06:05:10 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 06:05:10 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Stefan K ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/fdae7642..23569726 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=02-03 Stats: 35 lines in 3 files changed: 0 ins; 1 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 06:05:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 06:05:11 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:18:16 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.cpp line 1869: > >> 1867: return round_down_power_of_2(v2); >> 1868: } >> 1869: return 0; > > In next_larger you use the for: > if (v2 == 0) { > return 0; > } > return ... > I think it would be nice to be consistent between the two functions. > Just a few drive-by comment: Could PagesizeSet be named PageSizeSet. The rest of the code separates the word, so I think that name would be better. The same for some of the parameters that are named pagesize. > > Also, I think you could have called the class PageSizes. I don't think the fact that this is a 'set' matters for the usages of the class. It also makes the variable name match the type name, which I guess is an indication that it wouldn't be such a bad name: > > ``` > static PageSizes _page_sizes;` > ``` > > vs > > ``` > static PagesizeSet _page_sizes; > ``` Hi Stefan, thanks for your review! I adapted most of your suggestions. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From thomas.stuefe at gmail.com Fri Dec 4 07:31:44 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 4 Dec 2020 08:31:44 +0100 Subject: linux, large page initialization code question Message-ID: Hi, looking a the large-page initialization code, in os::Linux::find_default_large_page_size(). I see the following segment: ``` // If we can't determine the value (e.g. /proc is not mounted, or the text // format has been changed), we'll use the largest page size supported by // the processor. #ifndef ZERO large_page_size = AARCH64_ONLY(2 * M) AMD64_ONLY(2 * M) ARM32_ONLY(2 * M) IA32_ONLY(4 * M) IA64_ONLY(256 * M) PPC_ONLY(4 * M) S390_ONLY(1 * M); #endif // ZERO ``` This seems so strange: - can we simply assume a huge page size if the proc file system gives no indication for it? - planning on the proc file system format changing is probably unnecessary; it's well defined and will probably never change in an incompatible way. - and if /proc is not mounted, a lot of other things would not work, no? Is that even possible? I never saw a linux box without /proc - and why disabled for ZERO? What is the story behind this? The original change is lost to me (the earliest I looked into was jdk8), and the #ifndef zero change came in with "6890308: integrate zero assembler hotspot changes" without any explanation I could find. Bottom line, do we still need it? I think just assuming a large page size if the system is not configured for it is wrong. Thanks, Thomas From fweimer at redhat.com Fri Dec 4 08:30:24 2020 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 04 Dec 2020 09:30:24 +0100 Subject: linux, large page initialization code question In-Reply-To: ("Thomas =?utf-8?Q?St=C3=BCfe=22's?= message of "Fri, 4 Dec 2020 08:31:44 +0100") References: Message-ID: <87y2ieq8gv.fsf@oldenburg2.str.redhat.com> * Thomas St?fe: > - and if /proc is not mounted, a lot of other things would not work, no? Is > that even possible? I never saw a linux box without /proc It used to work on uniprocessor CPUs only, due to this glibc bug (if you want to call it that): Before the fix, the JVM would crash pretty quickly on multi-processor systems because necessary barriers were missing. With the glibc fix (which went into glibc 2.26), it seemed to work, based on my testing at the time. Whether that makes sense is a different question, of course. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From sjohanss at openjdk.java.net Fri Dec 4 09:17:55 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 4 Dec 2020 09:17:55 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: References: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> Message-ID: On Fri, 4 Dec 2020 04:09:14 GMT, Jie Fu wrote: >> Took a closer look at the test now, some comment below. > > Hi @kstefanj , > > Thanks for your review. > > The fix has been updated according to your comments. > > I don't check the exit value because I found different platforms may return different values (Zero on MacOS, but non-zero on Linux). > Maybe, It should return 0 on Linux too, which I think is more reasonable. > And I'd like to file another bug to fix it in the future. > > Thanks. > Best regards, > Jie It should be 0 on Linux and after the addition of `@requires os.family == "linux"` it should only be run on Linux. Doing some manual runs show that the JVM can't start with an ulimit as low as in the test. If the startup in the test is not successful I don't think the test has any value, so we need to find values that make it reliable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Fri Dec 4 09:42:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 4 Dec 2020 09:42:56 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: References: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> Message-ID: On Fri, 4 Dec 2020 09:14:53 GMT, Stefan Johansson wrote: > It should be 0 on Linux and after the addition of `@requires os.family == "linux"` it should only be run on Linux. Doing some manual runs show that the JVM can't start with an ulimit as low as in the test. If the startup in the test is not successful I don't think the test has any value, so we need to find values that make it reliable. Hi @kstefanj , The test is used to check whether the assert is triggered. Before the fix, it failed. After the fix, it passed. As I mentioned above, there seems to be another bug on Linux. It does return 0 on MacOS. And I also think it should return 0 on Linux. I'll file another bug to fix it. What do you think? Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From sjohanss at openjdk.java.net Fri Dec 4 10:16:18 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 4 Dec 2020 10:16:18 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: References: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> Message-ID: <-lpdukPLhMHF_rrpGiUpg81Gaa8S_u9IycRmwd30I3I=.32943dab-d48f-488b-aa3f-c77c166f4063@github.com> On Fri, 4 Dec 2020 09:40:16 GMT, Jie Fu wrote: >> It should be 0 on Linux and after the addition of `@requires os.family == "linux"` it should only be run on Linux. Doing some manual runs show that the JVM can't start with an ulimit as low as in the test. If the startup in the test is not successful I don't think the test has any value, so we need to find values that make it reliable. > >> It should be 0 on Linux and after the addition of `@requires os.family == "linux"` it should only be run on Linux. Doing some manual runs show that the JVM can't start with an ulimit as low as in the test. If the startup in the test is not successful I don't think the test has any value, so we need to find values that make it reliable. > > Hi @kstefanj , > > The test is used to check whether the assert is triggered. > Before the fix, it failed. > After the fix, it passed. > > As I mentioned above, there seems to be another bug on Linux. > It does return 0 on MacOS. > And I also think it should return 0 on Linux. > I'll file another bug to fix it. > > What do you think? > > Thanks. > Best regards, > Jie Yes it might check that the assert doesn't trigger, but if the test is not robust enough to always manage to execute `java -version` we might start to see other failures in that test. In some sense the test is just lucky that it fails in a way that a hs_err-file is not created. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Fri Dec 4 12:31:29 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 4 Dec 2020 12:31:29 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Check the exit status ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1492/files - new: https://git.openjdk.java.net/jdk/pull/1492/files/2c6ff74c..5017f63c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=03-04 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492 PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Fri Dec 4 12:35:12 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 4 Dec 2020 12:35:12 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v3] In-Reply-To: <-lpdukPLhMHF_rrpGiUpg81Gaa8S_u9IycRmwd30I3I=.32943dab-d48f-488b-aa3f-c77c166f4063@github.com> References: <8Sh9g66n72t2BiS27DB0ucD-Do2zZU_Uo2Wxn97lows=.084f8bc4-f4e4-4ca2-a3ed-7320feeae03f@github.com> <-lpdukPLhMHF_rrpGiUpg81Gaa8S_u9IycRmwd30I3I=.32943dab-d48f-488b-aa3f-c77c166f4063@github.com> Message-ID: On Fri, 4 Dec 2020 10:13:19 GMT, Stefan Johansson wrote: > Yes it might check that the assert doesn't trigger, but if the test is not robust enough to always manage to execute `java -version` we might start to see other failures in that test. In some sense the test is just lucky that it fails in a way that a hs_err-file is not created. Hi @kstefanj , After some experiments, I finally got a configuration which can return 0 on Linux. Could you please review it again? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From sjohanss at openjdk.java.net Fri Dec 4 12:40:19 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 4 Dec 2020 12:40:19 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:31:29 GMT, Jie Fu wrote: >> Hi all, >> >> Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. >> For example, this assert [1] fired on our testing boxes. >> >> It can be reproduced by the following two steps on Linux-64: >> 1) ulimit -v 8388608 >> 2) java -XX:MinHeapSize=5g -version >> The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. >> >> One more important fact is that this bug can be more common on Linux-32 systems. >> Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. >> >> Testing: >> - tier1 ~ tier3 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Check the exit status This looks better. I'll run it through or testing env to make sure it passes there as well. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1492 From vlivanov at openjdk.java.net Fri Dec 4 12:45:30 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 12:45:30 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v2] In-Reply-To: References: Message-ID: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html Vladimir Ivanov 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: - Introduce MethodData::MDHeader class - Merge branch 'master' into 8252049.md.leak - Cleanup - Merge branch 'master' into 8252049.md.leak - Minor refactoring - Fix native memory leak in ciMethodData ctor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1478/files - new: https://git.openjdk.java.net/jdk/pull/1478/files/8d429ef9..011b26ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=00-01 Stats: 32207 lines in 828 files changed: 19824 ins; 4170 del; 8213 mod Patch: https://git.openjdk.java.net/jdk/pull/1478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1478/head:pull/1478 PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Fri Dec 4 12:45:32 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 12:45:32 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v2] In-Reply-To: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> References: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> Message-ID: On Mon, 30 Nov 2020 13:42:44 GMT, Coleen Phillimore wrote: >> Vladimir Ivanov 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: >> >> - Introduce MethodData::MDHeader class >> - Merge branch 'master' into 8252049.md.leak >> - Cleanup >> - Merge branch 'master' into 8252049.md.leak >> - Minor refactoring >> - Fix native memory leak in ciMethodData ctor > > Changes requested by coleenp (Reviewer). Thanks for the feedback, David, Kim, and Coleen. I reworked the fix and moved the fields accessed by `ciMethodData` into a separate class which is then embedded into `MethodData`. Let me know what you think about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From hseigel at openjdk.java.net Fri Dec 4 13:11:18 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 4 Dec 2020 13:11:18 GMT Subject: RFR: JDK-8257732: Add TestJFRWithJMX.java to problem list for OL 8.2 until the issue =?UTF-8?B?aXPigKY=?= In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:49:07 GMT, Mikhailo Seledtsov wrote: > Problem list TestJFRWithJMX for OL 8.2 until the issue is resolved. Looks good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1612 From stefank at openjdk.java.net Fri Dec 4 14:26:24 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:24 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 06:05:10 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Stefan K I think this mostly looks good, but there are a number of cleanups that I'd like you to consider. src/hotspot/share/runtime/os.cpp line 1852: > 1850: ////// Implementation of PageSizes > 1851: > 1852: void os::PageSizes::add(size_t pagesize) { pagesize => page_size and the same for other places as well. src/hotspot/share/runtime/os.cpp line 1876: > 1874: return 0; > 1875: } > 1876: int l = exact_log2(pagesize) + 1; l is not a good variable name. It's too easy to mistake for 1, depending on font. src/hotspot/share/runtime/os.cpp line 1894: > 1892: size_t os::PageSizes::smallest() const { > 1893: assert(min_page_size() > 0, "Sanity"); > 1894: return next_larger(min_page_size() / 2); I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: return next_larger(1); and thereby get rid of the dependency on the odd min_page_size(). src/hotspot/share/runtime/os.hpp line 126: > 124: static OSThread* _starting_thread; > 125: static address _polling_page; > 126: static PageSizes _page_sizes; Indentation is off by two spaces test/hotspot/gtest/runtime/test_os.cpp line 612: > 610: static const int max_page_size_log2 = (int)(sizeof(size_t) * 8); > 611: > 612: TEST_VM(os, pagesizeset_test_range) { pagesizeset name needs to be updated. test/hotspot/gtest/runtime/test_os.cpp line 613: > 611: > 612: TEST_VM(os, pagesizeset_test_range) { > 613: for (int bit = min_page_size_log2; bit < max_page_size_log2; bit ++) { bit ++ => bit++ : the same in the rest of the file. test/hotspot/gtest/runtime/test_os.cpp line 610: > 608: > 609: static const int min_page_size_log2 = exact_log2(os::min_page_size()); > 610: static const int max_page_size_log2 = (int)(sizeof(size_t) * 8); Could this be simply BitsPerWord? test/hotspot/gtest/runtime/test_os.cpp line 617: > 615: const size_t s = (size_t)1 << bit; > 616: const size_t s2 = (size_t)1 << bit2; > 617: //tty->print_cr(SIZE_FORMAT " - " SIZE_FORMAT, s, s2); Remove? test/hotspot/gtest/runtime/test_os.cpp line 625: > 623: } > 624: ASSERT_EQ((size_t)0, pss.smallest()); > 625: ASSERT_EQ((size_t)0, pss.largest()); This doesn't have to be inside a double nested for loop. This could be single check done once. test/hotspot/gtest/runtime/test_os.cpp line 669: > 667: stringStream ss(buffer, sizeof(buffer)); > 668: pss.print_on(&ss); > 669: // tty->print_cr("%s", buffer); Remove? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Fri Dec 4 14:26:25 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:25 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:16:07 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.cpp line 1859: > >> 1857: bool os::PagesizeSet::is_set(size_t pagesize) const { >> 1858: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); >> 1859: return (_v & pagesize) > 0; > > Why is this `> 0` and not simply `!= 0` I'm not sure if you saw this comment, but is there a reason why > 0 is used here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Fri Dec 4 14:26:26 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:50:47 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1876: > >> 1874: return 0; >> 1875: } >> 1876: int l = exact_log2(pagesize) + 1; > > l is not a good variable name. It's too easy to mistake for 1, depending on font. FWIW, this calculation was non-obvious when reading this. Maybe something like this would be easier? Feel free to ignore if you don't like it. // Remove current and smaller page sizes size_t v2 = _v & ~(pagesize + (pagesize - 1)) if (v2 == 0) { return 0; } return (size_t)1 << count_trailing_zeros(v2); ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From mseledtsov at openjdk.java.net Fri Dec 4 16:41:11 2020 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 4 Dec 2020 16:41:11 GMT Subject: Integrated: JDK-8257732: Problem list TestJFRWithJMX for OL 8.2 until the issue is resolved In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:49:07 GMT, Mikhailo Seledtsov wrote: > Problem list TestJFRWithJMX for OL 8.2 until the issue is resolved. This pull request has now been integrated. Changeset: 3eb69460 Author: Mikhailo Seledtsov URL: https://git.openjdk.java.net/jdk/commit/3eb69460 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8257732: Problem list TestJFRWithJMX for OL 8.2 until the issue is resolved Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/1612 From stuefe at openjdk.java.net Fri Dec 4 16:46:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:46:15 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:48:25 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1852: > >> 1850: ////// Implementation of PageSizes >> 1851: >> 1852: void os::PageSizes::add(size_t pagesize) { > > pagesize => page_size and the same for other places as well. Oh missed that in your first review, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From iklam at openjdk.java.net Fri Dec 4 16:49:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 16:49:15 GMT Subject: RFR: 8257651: LambdaEagerInit.java test failed in 2 different ways In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 02:23:20 GMT, Calvin Cheung wrote: > Please review this simple change for fixing the 2 issues as described in the bug report. > > - exclude the test from the hotspot_appcds_dynamic test group. > > - compile Asserts.java so that the class file will be located under the following dir `.../JTwork/classes/.../runtime/cds/appcds/LambdaEagerInit.d/jdk/test/lib/` > > Passed hs-tier4 tests. Looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1616 From stuefe at openjdk.java.net Fri Dec 4 16:51:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:19 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> On Fri, 4 Dec 2020 14:08:09 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1894: > >> 1892: size_t os::PageSizes::smallest() const { >> 1893: assert(min_page_size() > 0, "Sanity"); >> 1894: return next_larger(min_page_size() / 2); > > I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: > return next_larger(1); > and thereby get rid of the dependency on the odd min_page_size(). True. Earlier implementation had a lop in next_larger. But now it does not matter. 1 is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 16:51:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:59:51 GMT, Stefan Karlsson wrote: >> src/hotspot/share/runtime/os.cpp line 1876: >> >>> 1874: return 0; >>> 1875: } >>> 1876: int l = exact_log2(pagesize) + 1; >> >> l is not a good variable name. It's too easy to mistake for 1, depending on font. > > FWIW, this calculation was non-obvious when reading this. Maybe something like this would be easier? Feel free to ignore if you don't like it. > // Remove current and smaller page sizes > size_t v2 = _v & ~(pagesize + (pagesize - 1)) > if (v2 == 0) { > return 0; > } > return (size_t)1 << count_trailing_zeros(v2); I like yours more. Its clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 16:51:20 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:20 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> Message-ID: On Fri, 4 Dec 2020 16:47:30 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1894: >> >>> 1892: size_t os::PageSizes::smallest() const { >>> 1893: assert(min_page_size() > 0, "Sanity"); >>> 1894: return next_larger(min_page_size() / 2); >> >> I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: >> return next_larger(1); >> and thereby get rid of the dependency on the odd min_page_size(). > > True. Earlier implementation had a lop in next_larger. But now it does not matter. 1 is fine. (Note that min_page_size should be really a constant, and named differently. I have this mentally marked as another small cleanup) ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From lfoltan at openjdk.java.net Fri Dec 4 17:03:14 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Fri, 4 Dec 2020 17:03:14 GMT Subject: RFR: 8257651: LambdaEagerInit.java test failed in 2 different ways In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 02:23:20 GMT, Calvin Cheung wrote: > Please review this simple change for fixing the 2 issues as described in the bug report. > > - exclude the test from the hotspot_appcds_dynamic test group. > > - compile Asserts.java so that the class file will be located under the following dir `.../JTwork/classes/.../runtime/cds/appcds/LambdaEagerInit.d/jdk/test/lib/` > > Passed hs-tier4 tests. Looks good Calvin! Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1616 From stuefe at openjdk.java.net Fri Dec 4 17:03:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:03:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 14:20:17 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > test/hotspot/gtest/runtime/test_os.cpp line 625: > >> 623: } >> 624: ASSERT_EQ((size_t)0, pss.smallest()); >> 625: ASSERT_EQ((size_t)0, pss.largest()); > > This doesn't have to be inside a double nested for loop. This could be single check done once. I think I just remove it. Its pretty pointless, since we test for smallest=largest=0, and since we later test each bit individually in lines 645ff. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From ccheung at openjdk.java.net Fri Dec 4 17:10:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 4 Dec 2020 17:10:13 GMT Subject: RFR: 8257651: LambdaEagerInit.java test failed in 2 different ways In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 16:46:30 GMT, Ioi Lam wrote: >> Please review this simple change for fixing the 2 issues as described in the bug report. >> >> - exclude the test from the hotspot_appcds_dynamic test group. >> >> - compile Asserts.java so that the class file will be located under the following dir `.../JTwork/classes/.../runtime/cds/appcds/LambdaEagerInit.d/jdk/test/lib/` >> >> Passed hs-tier4 tests. > > Looks good to me. Thanks @iklam and @lfoltan for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1616 From ccheung at openjdk.java.net Fri Dec 4 17:10:15 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 4 Dec 2020 17:10:15 GMT Subject: Integrated: 8257651: LambdaEagerInit.java test failed in 2 different ways In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 02:23:20 GMT, Calvin Cheung wrote: > Please review this simple change for fixing the 2 issues as described in the bug report. > > - exclude the test from the hotspot_appcds_dynamic test group. > > - compile Asserts.java so that the class file will be located under the following dir `.../JTwork/classes/.../runtime/cds/appcds/LambdaEagerInit.d/jdk/test/lib/` > > Passed hs-tier4 tests. This pull request has now been integrated. Changeset: d8ac76fa Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/d8ac76fa Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8257651: LambdaEagerInit.java test failed in 2 different ways Reviewed-by: iklam, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1616 From stuefe at openjdk.java.net Fri Dec 4 17:24:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:24:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Stefan (2) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/23569726..919d90bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=03-04 Stats: 38 lines in 3 files changed: 1 ins; 7 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 17:24:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:24:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 14:23:43 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > I think this mostly looks good, but there are a number of cleanups that I'd like you to consider. Hi Stefan, I pushed a new commit with the changes you requested. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From coleenp at openjdk.java.net Fri Dec 4 22:06:18 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 4 Dec 2020 22:06:18 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:45:30 GMT, Vladimir Ivanov wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > Vladimir Ivanov 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: > > - Introduce MethodData::MDHeader class > - Merge branch 'master' into 8252049.md.leak > - Cleanup > - Merge branch 'master' into 8252049.md.leak > - Minor refactoring > - Fix native memory leak in ciMethodData ctor This looks like a nice refactoring to me. src/hotspot/share/oops/methodData.hpp line 1972: > 1970: }; // Public flag values > 1971: > 1972: class MDHeader : public StackObj { MDHeader appears to be a Value Obj and not a StackObj, so it shouldn't inherit from StackObj. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Fri Dec 4 22:32:25 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 22:32:25 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v3] In-Reply-To: References: Message-ID: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: MDHeader shouldn't subclass StackObj ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1478/files - new: https://git.openjdk.java.net/jdk/pull/1478/files/011b26ca..af6b3d10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1478/head:pull/1478 PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Fri Dec 4 22:43:12 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 22:43:12 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v3] In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 19:48:14 GMT, Kim Barrett wrote: > But does there really need to be a mutex per MDO? Would a single immortal > mutex, shared by all MDOs, be adequate for this purpose? If not, maybe the > trick used by ObjectMonitor(?) -- have a set of immortal mutexes and > "randomly" choose one per MDO. This would also eliminate this part of the > walk of metadata objects to release heap resources when dropping them. And > it avoids constructing and destructing lots of mutexes (which isn't free, > even if not heap managed). Yes, I share the same concern about a mutex-per-MDO. Filed [JDK-8257756](https://bugs.openjdk.java.net/browse/JDK-8257756). ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Fri Dec 4 22:43:15 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 22:43:15 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 21:58:38 GMT, Coleen Phillimore wrote: >> Vladimir Ivanov 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: >> >> - Introduce MethodData::MDHeader class >> - Merge branch 'master' into 8252049.md.leak >> - Cleanup >> - Merge branch 'master' into 8252049.md.leak >> - Minor refactoring >> - Fix native memory leak in ciMethodData ctor > > src/hotspot/share/oops/methodData.hpp line 1972: > >> 1970: }; // Public flag values >> 1971: >> 1972: class MDHeader : public StackObj { > > MDHeader appears to be a Value Obj and not a StackObj, so it shouldn't inherit from StackObj. Fixed. And I was curious where `ValueObj`/`VALUE_OBJ_CLASS_SPEC` hide... :-) Until I learned from JDK-8173070 and JDK-8198243 that it was retired for good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From coleenp at openjdk.java.net Fri Dec 4 22:43:16 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 4 Dec 2020 22:43:16 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:35:35 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/oops/methodData.hpp line 1972: >> >>> 1970: }; // Public flag values >>> 1971: >>> 1972: class MDHeader : public StackObj { >> >> MDHeader appears to be a Value Obj and not a StackObj, so it shouldn't inherit from StackObj. > > Fixed. > > And I was curious where `ValueObj`/`VALUE_OBJ_CLASS_SPEC` hide... :-) Until I learned from JDK-8173070 and JDK-8198243 that it was retired for good. yes, it's gone. thanks for making this change. thumbs up. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From kbarrett at openjdk.java.net Sat Dec 5 02:04:16 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 5 Dec 2020 02:04:16 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v3] In-Reply-To: References: Message-ID: <5U2y31a5HXApv9FEAtc02SsCQBc-uzSoQYYYs9TD--g=.74cf87dd-90a4-497d-a9b3-bf88a4432557@github.com> On Fri, 4 Dec 2020 22:32:25 GMT, Vladimir Ivanov wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > MDHeader shouldn't subclass StackObj Mostly good; a few small suggestions or questions. src/hotspot/share/ci/ciMethodData.cpp line 227: > 225: // total_size = _data_size + _extra_data_size > 226: // args_data_limit = data_base + total_size - parameter_data_size > 227: assert(sizeof(_orig) % HeapWordSize == 0, "align"); Use static_assert. src/hotspot/share/ci/ciMethodData.cpp line 40: > 38: // ciMethodData::ciMethodData > 39: // > 40: ciMethodData::ciMethodData(MethodData* md) : ciMetadata(md), _orig() { For a future cleanup, a third, private, constructor could be added that does all the initialization, and the two public constructors could delegate to it, thereby eliminating a lot of code duplication. src/hotspot/share/oops/methodData.hpp line 1987: > 1985: public: > 1986: MDHeader() : _nof_decompiles(0), _nof_overflow_recompiles(0), _nof_overflow_traps(0) { > 1987: assert(sizeof(_trap_hist) % sizeof(HeapWord) == 0, "align"); static_assert. And should be consistent between here and next line as to `sizeof(HeapWord)` vs `HeapWordSize`. src/hotspot/share/oops/methodData.hpp line 1972: > 1970: }; // Public flag values > 1971: > 1972: class MDHeader { "header" seems like an odd naming choice for this. Should the name here be tied to the names in the comment in load_data? ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1478 From jiefu at openjdk.java.net Sat Dec 5 03:29:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 5 Dec 2020 03:29:17 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 Message-ID: Hi all, Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. So the correct assert should be: assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) It would be better to fix it. Testing: - Zero fastdebug build passed on Linux/x86_32 Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 ------------- Commit messages: - 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 Changes: https://git.openjdk.java.net/jdk/pull/1637/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1637&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257794 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1637/head:pull/1637 PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Sat Dec 5 04:43:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 5 Dec 2020 04:43:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> References: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> Message-ID: On Mon, 30 Nov 2020 13:42:56 GMT, Thomas Schatzl wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Check the exit status > > I think the change is good, but please add a test for this. > > E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. Hi @tschatzl , Are you OK with the latest change? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From david.holmes at oracle.com Sat Dec 5 05:22:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Dec 2020 15:22:10 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: Hi Erik, On 4/12/2020 12:07 am, Erik Joelsson wrote: > On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > >> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >> >> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >> >> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >> >> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >> >> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > make/modules/java.base/Lib.gmk line 131: > >> 129: ifeq ($(call isTargetOsType, unix), true) >> 130: ifeq ($(STATIC_BUILD), false) >> 131: LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"' > > In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag. I thought about just inlining it but it seemed "obvious" that LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it there - taking care to expand it in case it was set directly on the command-line. It also followed what is done for LIBJLI_CFLAGS. I can change it if you insist but this code will be very short-lived as I can remove it again in 17 once I no longer need the deprecation warning. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1587 > From david.holmes at oracle.com Sat Dec 5 05:27:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Dec 2020 15:27:10 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: <914d5630-fd3e-7f1e-25ca-f811a4a4a3a4@oracle.com> On 4/12/2020 12:42 am, Daniel D.Daugherty wrote: > On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > >> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >> >> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >> >> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >> >> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >> >> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > Thumbs up on the jsig.c change. No comment on the Lib.gmk change. Thanks for the review Dan! David > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1587 > From stuefe at openjdk.java.net Sat Dec 5 15:26:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 5 Dec 2020 15:26:11 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty wrote: >> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >> >> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >> >> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >> >> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >> >> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >> >> A CSR request has been filed. >> >> Testing: hotspot/jtreg/runtime/signal tests >> >> Thanks, >> David > > Thumbs up on the jsig.c change. No comment on the Lib.gmk change. Hi David, I am fine with this, but since this is possibly a breaking change would this not need a release note? ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From david.holmes at oracle.com Sun Dec 6 10:12:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Dec 2020 20:12:33 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: <1b51b51d-5e2b-5742-c586-a8d6a6671fd3@oracle.com> Hi Thomas, On 6/12/2020 1:26 am, Thomas Stuefe wrote: > On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty wrote: > >>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: >>> >>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html >>> >>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: >>> >>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) >>> >>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. >>> >>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. >>> >>> A CSR request has been filed. >>> >>> Testing: hotspot/jtreg/runtime/signal tests >>> >>> Thanks, >>> David >> >> Thumbs up on the jsig.c change. No comment on the Lib.gmk change. > > Hi David, > > I am fine with this, but since this is possibly a breaking change would this not need a release note? Well it isn't breaking anything at this stage as we are just issuing a deprecation warning. :) But yes I have filed a release note as well. Thanks, David > ..Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1587 > From stuefe at openjdk.java.net Sun Dec 6 10:26:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 6 Dec 2020 10:26:14 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: <1slEjsG2houlKUZGV24e4J3PrNEIFVZco4-5rvcUD_Y=.2869ceb6-1d9f-4110-a941-d41cdc10c0a7@github.com> On Sat, 5 Dec 2020 15:23:38 GMT, Thomas Stuefe wrote: >> Thumbs up on the jsig.c change. No comment on the Lib.gmk change. > > Hi David, > > I am fine with this, but since this is possibly a breaking change would this not need a release note? > > ..Thomas > > > > Hi David, > > I am fine with this, but since this is possibly a breaking change would this not need a release note? > > Well it isn't breaking anything at this stage as we are just issuing a > deprecation warning. :) But yes I have filed a release note as well. > > Thanks, > David Hi David, :) Thanks. The warning might elude customers until JDK17 comes around and things stop working. With signal chaining being out of scope for the typical java consultant, the expertise may have gone so customers may need to look for someone changing and recompiling their native solution. Or bug vendors to do so. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From sjohanss at openjdk.java.net Sun Dec 6 16:02:13 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Sun, 6 Dec 2020 16:02:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> Message-ID: On Sat, 5 Dec 2020 04:40:15 GMT, Jie Fu wrote: >> I think the change is good, but please add a test for this. >> >> E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. > > Hi @tschatzl , > > Are you OK with the latest change? > Thanks. Didn't see any problems with the test in the testing environment, so I'm good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From shade at openjdk.java.net Sun Dec 6 23:20:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 6 Dec 2020 23:20:11 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 03:25:10 GMT, Jie Fu wrote: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From dholmes at openjdk.java.net Mon Dec 7 02:41:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 02:41:12 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v3] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 22:32:25 GMT, Vladimir Ivanov wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > MDHeader shouldn't subclass StackObj Approval in principle from me. I'll let you work out naming details etc with Kim. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From minqi at openjdk.java.net Mon Dec 7 05:06:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 7 Dec 2020 05:06:20 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" Message-ID: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Hi, Please review Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. The fix is the first step of two steps: 1) Do not split reserved memory; 2) Remove splitting memory. This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. Tests:tier1-5,tier7 ------------- Commit messages: - 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" Changes: https://git.openjdk.java.net/jdk/pull/1657/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255917 Stats: 50 lines in 1 file changed: 25 ins; 8 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657 PR: https://git.openjdk.java.net/jdk/pull/1657 From jiefu at openjdk.java.net Mon Dec 7 07:02:29 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 07:02:29 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 [v2] In-Reply-To: References: Message-ID: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 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 three additional commits since the last revision: - Make the assert generic - Merge branch 'master' into JDK-8257794 - 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1637/files - new: https://git.openjdk.java.net/jdk/pull/1637/files/d60412a2..633034a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1637&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1637&range=00-01 Stats: 3084 lines in 69 files changed: 2408 ins; 476 del; 200 mod Patch: https://git.openjdk.java.net/jdk/pull/1637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1637/head:pull/1637 PR: https://git.openjdk.java.net/jdk/pull/1637 From shade at openjdk.java.net Mon Dec 7 07:40:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 07:40:12 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 03:25:10 GMT, Jie Fu wrote: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 @DamonFool, I don't think `/test` works here, or even makes sense: no current testing runs `Zero`. Please try to `make bootcycle-images` on platforms you can reach. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Mon Dec 7 07:40:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 07:40:13 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 03:25:10 GMT, Jie Fu wrote: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 > @DamonFool, I don't think `/test` works here, or even makes sense: no current testing runs `Zero`. Please try to `make bootcycle-images` on platforms you can reach. 'make bootcycle-images' have been done on Linux/86_32,64 and MacOS. All passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Mon Dec 7 07:40:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 07:40:14 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 23:17:08 GMT, Aleksey Shipilev wrote: > Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... The assert seems to be there at the creation of the OpenJDK repo. It was checked in at the second commit: commit 8153779ad32d1e8ddd37ced826c76c7aafc61894 Author: J. Duke Date: Sat Dec 1 00:00:00 2007 +0000 Initial load I had checked the debug version of jdk8's zero on Linx/x86_32 finding that it crashed due to the same reason. Maybe, the debug version of zero for x86_32 was broken at the very beginning. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From shade at openjdk.java.net Mon Dec 7 07:59:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 07:59:12 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 07:38:03 GMT, Jie Fu wrote: >> Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... > >> Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... > > The assert seems to be there at the creation of the OpenJDK repo. > It was checked in at the second commit: > commit 8153779ad32d1e8ddd37ced826c76c7aafc61894 > Author: J. Duke > Date: Sat Dec 1 00:00:00 2007 +0000 > > Initial load > > I had checked the debug version of jdk8's zero on Linx/x86_32 finding that it crashed due to the same reason. > Maybe, the debug version of zero for x86_32 was broken at the very beginning. All right, this makes more sense to me. @dholmes-ora, could you do us a favor and see why this line: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 ...was added? We don't have access to pre-OpenJDK history to get it ourselves. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From stefank at openjdk.java.net Mon Dec 7 08:16:16 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 7 Dec 2020 08:16:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Fri, 4 Dec 2020 17:24:26 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Stefan (2) Thanks! Looks good. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 08:52:28 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 08:52:28 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Add missing include (ppc,s390 builds failed) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/919d90bb..163b308b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 08:52:28 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 08:52:28 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Mon, 7 Dec 2020 08:13:21 GMT, Stefan Karlsson wrote: > Thanks! Looks good. Thank you Stefan. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From tschatzl at openjdk.java.net Mon Dec 7 09:16:15 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 7 Dec 2020 09:16:15 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> On Mon, 7 Dec 2020 08:52:28 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include (ppc,s390 builds failed) Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From tschatzl at openjdk.java.net Mon Dec 7 09:24:15 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 7 Dec 2020 09:24:15 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:31:29 GMT, Jie Fu wrote: >> Hi all, >> >> Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. >> For example, this assert [1] fired on our testing boxes. >> >> It can be reproduced by the following two steps on Linux-64: >> 1) ulimit -v 8388608 >> 2) java -XX:MinHeapSize=5g -version >> The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. >> >> One more important fact is that this bug can be more common on Linux-32 systems. >> Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. >> >> Testing: >> - tier1 ~ tier3 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Check the exit status Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Mon Dec 7 09:30:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 09:30:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:37:42 GMT, Stefan Johansson wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Check the exit status > > This looks better. I'll run it through or testing env to make sure it passes there as well. Thanks @kstefanj and @tschatzl for your review and help. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Mon Dec 7 09:30:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 09:30:17 GMT Subject: Integrated: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: <4Vg0448OBEokoCLHwbq4_z96jtvgemeBIxaboZJUyv0=.2689c0b6-12aa-41cf-99ed-1b6110fae075@github.com> On Sat, 28 Nov 2020 13:08:38 GMT, Jie Fu wrote: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 This pull request has now been integrated. Changeset: 7620124e Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/7620124e Stats: 62 lines in 2 files changed: 60 ins; 2 del; 0 mod 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From stuefe at openjdk.java.net Mon Dec 7 10:36:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 10:36:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> Message-ID: On Mon, 7 Dec 2020 09:13:20 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include (ppc,s390 builds failed) > > Marked as reviewed by tschatzl (Reviewer). Thanks Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 10:36:18 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 10:36:18 GMT Subject: Integrated: JDK-8257588: Make os::_page_sizes a bitmask In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Mon, 30 Nov 2020 16:48:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 This pull request has now been integrated. Changeset: 8e8e5845 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/8e8e5845 Stats: 228 lines in 7 files changed: 171 ins; 30 del; 27 mod 8257588: Make os::_page_sizes a bitmask Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 11:47:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 11:47:12 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi wrote: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Hi Yumin, small request wrt to commenting. We should test this with all permutations of NativeMemoryTracking and Xshare. But I guess the standard tests do this already? Cheers, Thomas src/hotspot/share/memory/metaspaceShared.cpp line 1629: > 1627: return NULL; > 1628: } > 1629: } else { Could we have a comment explaining all this? I am sure I will have forgotten why we did this in two months :) Proposal: On Windows, we cannot safely split a reserved area into two (see JDK-xxxx). Hence, we optimistically reserve archive space and class space side-by-side. We only do this for use_archive_base_addr=true since for the use_archive_base_addr=false case caller will not split the combined space but read the archive data via sequential file IO. Feel free to reformulate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From david.holmes at oracle.com Mon Dec 7 12:00:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 22:00:25 +1000 Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: <1983c892-fd26-740d-da57-ce72765cbd78@oracle.com> On 7/12/2020 5:59 pm, Aleksey Shipilev wrote: > On Mon, 7 Dec 2020 07:38:03 GMT, Jie Fu wrote: > >>> Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... >> >>> Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... >> >> The assert seems to be there at the creation of the OpenJDK repo. >> It was checked in at the second commit: >> commit 8153779ad32d1e8ddd37ced826c76c7aafc61894 >> Author: J. Duke >> Date: Sat Dec 1 00:00:00 2007 +0000 >> >> Initial load >> >> I had checked the debug version of jdk8's zero on Linx/x86_32 finding that it crashed due to the same reason. >> Maybe, the debug version of zero for x86_32 was broken at the very beginning. > > All right, this makes more sense to me. @dholmes-ora, could you do us a favor and see why this line: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > > ...was added? We don't have access to pre-OpenJDK history to get it ourselves. It came in as part of: https://bugs.openjdk.java.net/browse/JDK-6571248 but there is no additional information. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1637 > From david.holmes at oracle.com Mon Dec 7 12:04:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 22:04:06 +1000 Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: <32ef94ec-30e8-43a1-5f32-6d43a0dcde07@oracle.com> On 7/12/2020 7:30 pm, Jie Fu wrote: > On Fri, 4 Dec 2020 12:37:42 GMT, Stefan Johansson wrote: > >>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Check the exit status >> >> This looks better. I'll run it through or testing env to make sure it passes there as well. > > Thanks @kstefanj and @tschatzl for your review and help. We are seeing the new test crash on Aarch64 due to native OOM. https://bugs.openjdk.java.net/browse/JDK-8257820 Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1492 > From jiefu at openjdk.java.net Mon Dec 7 12:06:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 12:06:14 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 07:56:36 GMT, Aleksey Shipilev wrote: >>> Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... >> >> The assert seems to be there at the creation of the OpenJDK repo. >> It was checked in at the second commit: >> commit 8153779ad32d1e8ddd37ced826c76c7aafc61894 >> Author: J. Duke >> Date: Sat Dec 1 00:00:00 2007 +0000 >> >> Initial load >> >> I had checked the debug version of jdk8's zero on Linx/x86_32 finding that it crashed due to the same reason. >> Maybe, the debug version of zero for x86_32 was broken at the very beginning. > > All right, this makes more sense to me. @dholmes-ora, could you do us a favor and see why this line: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > > ...was added? We don't have access to pre-OpenJDK history to get it ourselves. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > On 7/12/2020 5:59 pm, Aleksey Shipilev wrote: > > > On Mon, 7 Dec 2020 07:38:03 GMT, Jie Fu wrote: > > > > Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... > > > > > > > > > > Hold on a sec, I meant to see why the assert is there, and why it is in that form, and why it is `IA32_ONLY`. It should either be a generic assert (if it is good assert), or removed completely (if it is a superfluous assert). Code history should reveal the answer to that... > > > > > > > > > The assert seems to be there at the creation of the OpenJDK repo. > > > It was checked in at the second commit: > > > commit [8153779](https://github.com/openjdk/jdk/commit/8153779ad32d1e8ddd37ced826c76c7aafc61894) > > > Author: J. Duke > > > Date: Sat Dec 1 00:00:00 2007 +0000 > > > ``` > > > Initial load > > > ``` > > > > > > > > > I had checked the debug version of jdk8's zero on Linx/x86_32 finding that it crashed due to the same reason. > > > Maybe, the debug version of zero for x86_32 was broken at the very beginning. > > > > > > All right, this makes more sense to me. @dholmes-ora, could you do us a favor and see why this line: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > > ...was added? We don't have access to pre-OpenJDK history to get it ourselves. > > It came in as part of: > > https://bugs.openjdk.java.net/browse/JDK-6571248 > > but there is no additional information. > > Cheers, > David I will have a look. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Mon Dec 7 12:15:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 12:15:14 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 09:27:02 GMT, Jie Fu wrote: >> This looks better. I'll run it through or testing env to make sure it passes there as well. > > Thanks @kstefanj and @tschatzl for your review and help. > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > On 7/12/2020 7:30 pm, Jie Fu wrote: > > > On Fri, 4 Dec 2020 12:37:42 GMT, Stefan Johansson wrote: > > > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > > > Check the exit status > > > > > > > > > This looks better. I'll run it through or testing env to make sure it passes there as well. > > > > > > Thanks @kstefanj and @tschatzl for your review and help. > > We are seeing the new test crash on Aarch64 due to native OOM. > > https://bugs.openjdk.java.net/browse/JDK-8257820 > > Cheers, > David Is it always reproducible? I'll try to find an aarch64 machine to reproduce it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From sjohanss at openjdk.java.net Mon Dec 7 12:20:13 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 7 Dec 2020 12:20:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:12:35 GMT, Jie Fu wrote: >> Thanks @kstefanj and @tschatzl for your review and help. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ >> >> On 7/12/2020 7:30 pm, Jie Fu wrote: >> >> > On Fri, 4 Dec 2020 12:37:42 GMT, Stefan Johansson wrote: >> > > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> > > > Check the exit status >> > > >> > > >> > > This looks better. I'll run it through or testing env to make sure it passes there as well. >> > >> > >> > Thanks @kstefanj and @tschatzl for your review and help. >> >> We are seeing the new test crash on Aarch64 due to native OOM. >> >> https://bugs.openjdk.java.net/browse/JDK-8257820 >> >> Cheers, >> David > > Is it always reproducible? > I'll try to find an aarch64 machine to reproduce it. > Thanks. I had hoped my testing would have caught this, but might be that the test is to brittle after all. I saw it pass on aarch64, so not happening every time. I would be good with removing the test as a fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From david.holmes at oracle.com Mon Dec 7 12:22:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 22:22:14 +1000 Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: On 7/12/2020 10:15 pm, Jie Fu wrote: > On Mon, 7 Dec 2020 09:27:02 GMT, Jie Fu wrote: > >>> This looks better. I'll run it through or testing env to make sure it passes there as well. >> >> Thanks @kstefanj and @tschatzl for your review and help. > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ >> >> On 7/12/2020 7:30 pm, Jie Fu wrote: >> >>> On Fri, 4 Dec 2020 12:37:42 GMT, Stefan Johansson wrote: >>>>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >>>>> Check the exit status >>>> >>>> >>>> This looks better. I'll run it through or testing env to make sure it passes there as well. >>> >>> >>> Thanks @kstefanj and @tschatzl for your review and help. >> >> We are seeing the new test crash on Aarch64 due to native OOM. >> >> https://bugs.openjdk.java.net/browse/JDK-8257820 >> >> Cheers, >> David > > Is it always reproducible? No. It passed when this commit was integrated, but then failed in later test runs. David > I'll try to find an aarch64 machine to reproduce it. > Thanks. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1492 > From jiefu at openjdk.java.net Mon Dec 7 12:27:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 12:27:13 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: References: Message-ID: <2zbxEKMoFBOqompGsQ1hV3CXHFquMXBlorQi8De3sZY=.6b2da533-8d51-4516-b3da-9f7fa6db426d@github.com> On Mon, 7 Dec 2020 12:17:53 GMT, Stefan Johansson wrote: > I had hoped my testing would have caught this, but might be that the test is to brittle after all. I saw it pass on aarch64, so not happening every time. > > I would be good with removing the test as a fix. OK. I'm fine to remove it and will do it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Mon Dec 7 12:31:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 7 Dec 2020 12:31:14 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes [v5] In-Reply-To: <2zbxEKMoFBOqompGsQ1hV3CXHFquMXBlorQi8De3sZY=.6b2da533-8d51-4516-b3da-9f7fa6db426d@github.com> References: <2zbxEKMoFBOqompGsQ1hV3CXHFquMXBlorQi8De3sZY=.6b2da533-8d51-4516-b3da-9f7fa6db426d@github.com> Message-ID: <9XNx3VgWz0DrcCM6v6vZgziL4t-JtW_-_8wOXQmtO9g=.2608c79a-23de-4064-80ec-a661d0f6170f@github.com> On Mon, 7 Dec 2020 12:24:52 GMT, Jie Fu wrote: > > I had hoped my testing would have caught this, but might be that the test is to brittle after all. I saw it pass on aarch64, so not happening every time. > > I would be good with removing the test as a fix. > > OK. > I'm fine to remove it and will do it soon. It has been assigned to @tschatzl . Thanks for fixing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From erik.joelsson at oracle.com Mon Dec 7 13:35:34 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Dec 2020 05:35:34 -0800 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com> On 2020-12-04 21:22, David Holmes wrote: > Hi Erik, > > On 4/12/2020 12:07 am, Erik Joelsson wrote: >> >> In general, I would prefer if a flag like this was just inlined in >> the SetupJdkLibrary call, as there are no complex conditionals for >> setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is >> dead and not set anywhere in the build, so could also just be removed >> and replaced with your new -D flag. > > I thought about just inlining it but it seemed "obvious" that > LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it > there - taking care to expand it in case it was set directly on the > command-line. It also followed what is done for LIBJLI_CFLAGS. > > I can change it if you insist but this code will be very short-lived > as I can remove it again in 17 once I no longer need the deprecation > warning. > If you think there is a case for overriding this on the command line, then sure, we can keep it. From what I can see, this is just a left over from when some more complicated logic was needed, or these flags needed to be reused somewhere else. In the case of libjli, we reuse the flags in several different versions of the SetupJdkLibrary call for libjli. That said, I won't insist strongly on this. /Erik From erikj at openjdk.java.net Mon Dec 7 13:41:12 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Dec 2020 13:41:12 GMT Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From vlivanov at openjdk.java.net Mon Dec 7 15:38:28 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 7 Dec 2020 15:38:28 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v4] In-Reply-To: References: Message-ID: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1478/files - new: https://git.openjdk.java.net/jdk/pull/1478/files/af6b3d10..50a695a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=02-03 Stats: 77 lines in 7 files changed: 3 ins; 26 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/1478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1478/head:pull/1478 PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Mon Dec 7 15:43:13 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 7 Dec 2020 15:43:13 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v3] In-Reply-To: References: Message-ID: <8yBkA1lnVhTDEH-veGvWtoT00dGlQSwp1UCMWCiI8xU=.df28b1d9-7160-4527-96d5-656c444fc007@github.com> On Mon, 7 Dec 2020 02:38:41 GMT, David Holmes wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> MDHeader shouldn't subclass StackObj > > Approval in principle from me. I'll let you work out naming details etc with Kim. > > Thanks, > David Kim, agree on all your comments/suggestions. Let me know what you think about the latest version. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From minqi at openjdk.java.net Mon Dec 7 17:02:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 7 Dec 2020 17:02:15 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: On Mon, 7 Dec 2020 11:44:33 GMT, Thomas Stuefe wrote: > Hi Yumin, > > small request wrt to commenting. > > We should test this with all permutations of NativeMemoryTracking and Xshare. But I guess the standard tests do this already? > > Cheers, Thomas Thanks for the review! There are permutation on standard tests, I will give another look if they cover all the cases again. I think it is enough so no need for a new test case but will check again. Thanks Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From minqi at openjdk.java.net Mon Dec 7 18:08:25 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 7 Dec 2020 18:08:25 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Add comment for reserve archive space and ccs on windows when mapping on required address ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1657/files - new: https://git.openjdk.java.net/jdk/pull/1657/files/1d2f5959..dd9ae050 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657 PR: https://git.openjdk.java.net/jdk/pull/1657 From iklam at openjdk.java.net Mon Dec 7 18:08:26 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 7 Dec 2020 18:08:26 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: On Mon, 7 Dec 2020 18:05:21 GMT, Yumin Qi wrote: >> Hi, Please review >> Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. >> The fix is the first step of two steps: >> 1) Do not split reserved memory; >> 2) Remove splitting memory. >> This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Add comment for reserve archive space and ccs on windows when mapping on required address Changes requested by iklam (Reviewer). src/hotspot/share/memory/metaspaceShared.cpp line 1655: > 1653: archive_space_rs = total_rs.first_part(ccs_begin_offset, > 1654: (size_t)os::vm_allocation_granularity(), > 1655: /*split=*/false); Since `/*split=*/false` is passed, the region is no longer split using `os::split_reserved_memory()`. This means on Windows, we cannot use `os::release_memory()` to free the individual regions of `archive_space_rs` and `class_space_rs`. The Windows API of [VirtualFree](https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree) says: > Releases the specified region of pages, or placeholder [...], `dwSize` must be 0 (zero), and `lpAddress` must point to the base address returned by the `VirtualAlloc` function when the region is reserved. The function fails if either of these conditions is not met. I suggest we do this: - Add an extra `ReservedSpace& total_rs` parameter to `MetaspaceShared::reserve_address_space_for_archives()`. Return the `total_rs` when we go through this path of the code. - Also pass `total_rs` to `MetaspaceShared::release_reserved_spaces`. If `total_rs.is_reserverd()` is true, release `total_rs` instead of the two smaller spaces. To make sure this PR is correct, we should add something like the following in `os::release_memory()`, and check for this log in test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java: if (!res) { log_info(os)("os::release_memory(" PTR_FORMAT ", " SIZE_FORMAT ") failed", p2i(addr), bytes); } Perhaps, in a separate RFE, we should add an assert in `os::release_memory()`, or at least change the `log_info` to `log_warning`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From gziemski at openjdk.java.net Mon Dec 7 21:31:19 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 7 Dec 2020 21:31:19 GMT Subject: RFR: 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests Message-ID: This is a workaround for GCC 5.4 bug that is triggered by a particular pattern of math header usage as is the case here with our gtest suite. Thank you to Mikael Vidstedt for finding the GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 , triggered by gtest usage as described here https://github.com/google/googletest/commit/fe4d5f10840c5f62b984364a4d41719f1bc079a2 Thank you to Ioi for debugging the issue and coming up with the workaround used in this fix. ------------- Commit messages: - workaround gcc math header bug Changes: https://git.openjdk.java.net/jdk/pull/1678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252797 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1678/head:pull/1678 PR: https://git.openjdk.java.net/jdk/pull/1678 From david.holmes at oracle.com Mon Dec 7 21:52:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2020 07:52:12 +1000 Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com> References: <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com> Message-ID: On 7/12/2020 11:35 pm, Erik Joelsson wrote: > > On 2020-12-04 21:22, David Holmes wrote: >> Hi Erik, >> >> On 4/12/2020 12:07 am, Erik Joelsson wrote: >>> >>> In general, I would prefer if a flag like this was just inlined in >>> the SetupJdkLibrary call, as there are no complex conditionals for >>> setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is >>> dead and not set anywhere in the build, so could also just be removed >>> and replaced with your new -D flag. >> >> I thought about just inlining it but it seemed "obvious" that >> LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it >> there - taking care to expand it in case it was set directly on the >> command-line. It also followed what is done for LIBJLI_CFLAGS. >> >> I can change it if you insist but this code will be very short-lived >> as I can remove it again in 17 once I no longer need the deprecation >> warning. >> > If you think there is a case for overriding this on the command line, > then sure, we can keep it. From what I can see, this is just a left over > from when some more complicated logic was needed, or these flags needed > to be reused somewhere else. In the case of libjli, we reuse the flags > in several different versions of the SetupJdkLibrary call for libjli. > That said, I won't insist strongly on this. Thanks Erik I appreciate that as I just want to get this pushed ASAP. David > /Erik > > From gziemski at openjdk.java.net Mon Dec 7 21:55:25 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 7 Dec 2020 21:55:25 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() Message-ID: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. ------------- Commit messages: - update to latest - fix potential sa_handler/sa_sigaction overlap storage issue Changes: https://git.openjdk.java.net/jdk/pull/1680/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251438 Stats: 26 lines in 1 file changed: 11 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1680/head:pull/1680 PR: https://git.openjdk.java.net/jdk/pull/1680 From dholmes at openjdk.java.net Mon Dec 7 21:59:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 21:59:12 GMT Subject: Integrated: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote: > The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction: > > https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html > > Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages: > > sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.) > > signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. > > We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17. > > A CSR request has been filed. > > Testing: hotspot/jtreg/runtime/signal tests > > Thanks, > David This pull request has now been integrated. Changeset: 149a02f9 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/149a02f9 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Reviewed-by: ihse, alanb, dcubed, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/1587 From dholmes at openjdk.java.net Mon Dec 7 23:31:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Dec 2020 23:31:11 GMT Subject: RFR: 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 21:15:32 GMT, Gerard Ziemski wrote: > This is a workaround for GCC 5.4 bug that is triggered by a particular pattern of math header usage as is the case here with our gtest suite. > > Thank you to Mikael Vidstedt for finding the GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 , triggered by gtest usage as described here https://github.com/google/googletest/commit/fe4d5f10840c5f62b984364a4d41719f1bc079a2 > > Thank you to Ioi for debugging the issue and coming up with the workaround used in this fix. Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1678 From kbarrett at openjdk.java.net Tue Dec 8 01:56:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 01:56:13 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v4] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 15:38:28 GMT, Vladimir Ivanov wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Cleanups One lingering question. The name CompilerCounters seems much better, BTW. src/hotspot/share/oops/methodData.hpp line 1987: > 1985: > 1986: public: > 1987: CompilerCounters() : _nof_decompiles(0), _nof_overflow_recompiles(0), _nof_overflow_traps(0) { This doesn't initialize _creation_mileage. Is that a bug? Should that be a constructor argument? ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From ksakata at openjdk.java.net Tue Dec 8 04:52:17 2020 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Tue, 8 Dec 2020 04:52:17 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options Message-ID: In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). But it?s possible to specify options with more colons like `java -Xlog:::::`. It?s better to show a message when more options are specified than maximum number. By this PR a warning message is outputted when options are specified more than the max number. ------------- Commit messages: - Check the number of options in -Xlog Changes: https://git.openjdk.java.net/jdk/pull/1685/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1685&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257872 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1685/head:pull/1685 PR: https://git.openjdk.java.net/jdk/pull/1685 From minqi at openjdk.java.net Tue Dec 8 05:49:30 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 8 Dec 2020 05:49:30 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: > Hi, Please review > Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space. > The fix is the first step of two steps: > 1) Do not split reserved memory; > 2) Remove splitting memory. > This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. > > Tests:tier1-5,tier7 Yumin Qi 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 35 additional commits since the last revision: - Merge branch 'master' into jdk-8255917 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test. - 8253762: JFR: getField(String) should be able to access subfields Reviewed-by: mgronlun - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Reviewed-by: jnimeh - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32 Reviewed-by: kvn - 8257211: C2: Enable call devirtualization during post-parse phase Reviewed-by: kvn, neliasso, thartmann - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal Reviewed-by: ihse, alanb, dcubed, erikj - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs Reviewed-by: redestad, kvn - 8257799: Update JLS cross-references in java.compiler Reviewed-by: jjg - 8254939: macOS: unused function 'replicate4_imm' Reviewed-by: redestad, thartmann - ... and 25 more: https://git.openjdk.java.net/jdk/compare/03059f36...7b93584f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1657/files - new: https://git.openjdk.java.net/jdk/pull/1657/files/f7958306..7b93584f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1657.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657 PR: https://git.openjdk.java.net/jdk/pull/1657 From minqi at openjdk.java.net Tue Dec 8 06:15:16 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 8 Dec 2020 06:15:16 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: On Mon, 7 Dec 2020 18:05:03 GMT, Ioi Lam wrote: >> Yumin Qi 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 35 additional commits since the last revision: >> >> - Merge branch 'master' into jdk-8255917 >> - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test. >> - 8253762: JFR: getField(String) should be able to access subfields >> >> Reviewed-by: mgronlun >> - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks >> >> Reviewed-by: jnimeh >> - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32 >> >> Reviewed-by: kvn >> - 8257211: C2: Enable call devirtualization during post-parse phase >> >> Reviewed-by: kvn, neliasso, thartmann >> - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal >> >> Reviewed-by: ihse, alanb, dcubed, erikj >> - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs >> >> Reviewed-by: redestad, kvn >> - 8257799: Update JLS cross-references in java.compiler >> >> Reviewed-by: jjg >> - 8254939: macOS: unused function 'replicate4_imm' >> >> Reviewed-by: redestad, thartmann >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/ca67e32d...7b93584f > > Changes requested by iklam (Reviewer). Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From dholmes at openjdk.java.net Tue Dec 8 06:16:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Dec 2020 06:16:14 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options In-Reply-To: References: Message-ID: <-aCSMWn3fc0CpNpCNdc8w0kiKm2C07qLkNpLhKNV9u4=.5e81a884-07b8-4896-9422-3120b2e32238@github.com> On Tue, 8 Dec 2020 03:02:03 GMT, Koichi Sakata wrote: > In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). > But it?s possible to specify options with more colons like `java -Xlog:::::`. > It?s better to show a message when more options are specified than maximum number. > > By this PR a warning message is outputted when options are specified more than the max number. src/hotspot/share/logging/logConfiguration.cpp line 371: > 369: > 370: if (str != NULL) { > 371: log_warning(logging)("Options are specified more than the max number in -Xlog."); Might I suggest: `log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);` ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From shade at openjdk.java.net Tue Dec 8 08:42:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 08:42:12 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 [v2] In-Reply-To: References: Message-ID: <9JgrE-bSF3KDnd5xRwraBNmzwFGrv2Nw99oEFLCPaHc=.bd76571c-6275-4047-8ba3-528093829221@github.com> On Mon, 7 Dec 2020 07:02:29 GMT, Jie Fu wrote: >> Hi all, >> >> Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. >> >> 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. >> 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. >> >> So the correct assert should be: >> assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) >> >> It would be better to fix it. >> >> Testing: >> - Zero fastdebug build passed on Linux/x86_32 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 > > 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 three additional commits since the last revision: > > - Make the assert generic > - Merge branch 'master' into JDK-8257794 > - 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 After looking closer, I think this assert is not very useful, it is already disabled on all platforms except x86_32, and it is probably a leftover after many bulk Zero integrations. I think it is fine, safer, faster to remove it for all platforms. Do it, and I'll approve. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Tue Dec 8 09:18:23 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 09:18:23 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 [v3] In-Reply-To: References: Message-ID: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Remove the assert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1637/files - new: https://git.openjdk.java.net/jdk/pull/1637/files/633034a3..34e35cc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1637&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1637&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1637/head:pull/1637 PR: https://git.openjdk.java.net/jdk/pull/1637 From shade at openjdk.java.net Tue Dec 8 09:18:24 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Dec 2020 09:18:24 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 09:15:54 GMT, Jie Fu wrote: >> Hi all, >> >> Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. >> >> 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. >> 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. >> >> So the correct assert should be: >> assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) >> >> It would be better to fix it. >> >> Testing: >> - Zero fastdebug build passed on Linux/x86_32 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 >> [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove the assert Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From jiefu at openjdk.java.net Tue Dec 8 09:18:24 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 8 Dec 2020 09:18:24 GMT Subject: RFR: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 [v2] In-Reply-To: <9JgrE-bSF3KDnd5xRwraBNmzwFGrv2Nw99oEFLCPaHc=.bd76571c-6275-4047-8ba3-528093829221@github.com> References: <9JgrE-bSF3KDnd5xRwraBNmzwFGrv2Nw99oEFLCPaHc=.bd76571c-6275-4047-8ba3-528093829221@github.com> Message-ID: On Tue, 8 Dec 2020 08:39:45 GMT, Aleksey Shipilev wrote: > After looking closer, I think this assert is not very useful, it is already disabled on all platforms except x86_32, and it is probably a leftover after many bulk Zero integrations. I think it is fine, safer, faster to remove it for all platforms. Do it, and I'll approve. Yes, I agree. Done. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From stuefe at openjdk.java.net Tue Dec 8 10:10:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 10:10:17 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> Message-ID: <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> On Mon, 7 Dec 2020 18:04:52 GMT, Ioi Lam wrote: >> Yumin Qi 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 35 additional commits since the last revision: >> >> - Merge branch 'master' into jdk-8255917 >> - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test. >> - 8253762: JFR: getField(String) should be able to access subfields >> >> Reviewed-by: mgronlun >> - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks >> >> Reviewed-by: jnimeh >> - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32 >> >> Reviewed-by: kvn >> - 8257211: C2: Enable call devirtualization during post-parse phase >> >> Reviewed-by: kvn, neliasso, thartmann >> - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal >> >> Reviewed-by: ihse, alanb, dcubed, erikj >> - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs >> >> Reviewed-by: redestad, kvn >> - 8257799: Update JLS cross-references in java.compiler >> >> Reviewed-by: jjg >> - 8254939: macOS: unused function 'replicate4_imm' >> >> Reviewed-by: redestad, thartmann >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/8bc10d13...7b93584f > > src/hotspot/share/memory/metaspaceShared.cpp line 1655: > >> 1653: archive_space_rs = total_rs.first_part(ccs_begin_offset, >> 1654: (size_t)os::vm_allocation_granularity(), >> 1655: /*split=*/false); > > Since `/*split=*/false` is passed, the region is no longer split using `os::split_reserved_memory()`. This means on Windows, we cannot use `os::release_memory()` to free the individual regions of `archive_space_rs` and `class_space_rs`. > > The Windows API of [VirtualFree](https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree) says: > >> Releases the specified region of pages, or placeholder [...], `dwSize` must be 0 (zero), and `lpAddress` must point to the base address returned by the `VirtualAlloc` function when the region is reserved. The function fails if either of these conditions is not met. > > I suggest we do this: > > - Add an extra `ReservedSpace& total_rs` parameter to `MetaspaceShared::reserve_address_space_for_archives()`. Return the `total_rs` when we go through this path of the code. > - Also pass `total_rs` to `MetaspaceShared::release_reserved_spaces`. If `total_rs.is_reserverd()` is true, release `total_rs` instead of the two smaller spaces. > > To make sure this PR is correct, we should add something like the following in `os::release_memory()`, and check for this log in test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java: > > if (!res) { > log_info(os)("os::release_memory(" PTR_FORMAT ", " SIZE_FORMAT ") failed", p2i(addr), bytes); > } > > Perhaps, in a separate RFE, we should add an assert in `os::release_memory()`, or at least change the `log_info` to `log_warning`. Hi Ioi, Where is the release you worry about? Since on Windows, since 8255978, os::release_memory() notices if the region the caller wants release does not correspond exactly to a memory mapping at the OS level, and will assert. Do you see that assert? I try to understand: if useBaseAddress==true, Yumin now creates two separate mappings, and can release them individually if useBaseAddress==false, there is one mapping as before, but we split now shallow. But we don't release it since we use file IO to read into it. If someone were to release one of those, we should see an assert on Windows. (I am a tiny bit unhappy about the increasing complexity of the patch, since it negates some of the work done to simplify it back in June.) About tracing, since 8256864 we trace Virtualxxx calls, so the tracing is already there - we trace VirtualFree() errrors for "os=info". If you only care for windows, that tracing could suffice. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From vlivanov at openjdk.java.net Tue Dec 8 11:08:24 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Dec 2020 11:08:24 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: creation_mileage cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1478/files - new: https://git.openjdk.java.net/jdk/pull/1478/files/50a695a4..2b7cb548 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=03-04 Stats: 9 lines in 2 files changed: 4 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1478/head:pull/1478 PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Tue Dec 8 11:08:24 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Dec 2020 11:08:24 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v4] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 01:48:53 GMT, Kim Barrett wrote: > This doesn't initialize _creation_mileage. Is that a bug? Should that be a constructor argument? I don't think there's a bug since `MethodData` initializes it right away (and `ciMethodData` bulk copies it from the original version), but agree passing it as a constructor argument is cleaner. Updated version posted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From kbarrett at openjdk.java.net Tue Dec 8 11:15:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 11:15:13 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:08:24 GMT, Vladimir Ivanov wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > creation_mileage cleanup Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From vlivanov at openjdk.java.net Tue Dec 8 11:20:12 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Dec 2020 11:20:12 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:12:45 GMT, Kim Barrett wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> creation_mileage cleanup > > Marked as reviewed by kbarrett (Reviewer). Thanks for the reviews, Kim, Coleen, and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From stuefe at openjdk.java.net Tue Dec 8 14:42:24 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 14:42:24 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads Message-ID: In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: JavaThread* thread = NULL; ... if(t->is_Java_thread()) { thread = (JavaThread*)t; } ... if (info != NULL && uc != NULL && thread != NULL) { pc = (address) os::Linux::ucontext_get_pc(uc); if (StubRoutines::is_safefetch_fault(pc)) { As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. ---- The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. I added a gtest which reproduces the issue and used that to check that the patch works. Thanks, Thomas ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1695/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1695&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Stats: 170 lines in 11 files changed: 94 ins; 74 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1695/head:pull/1695 PR: https://git.openjdk.java.net/jdk/pull/1695 From gziemski at openjdk.java.net Tue Dec 8 15:41:12 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 8 Dec 2020 15:41:12 GMT Subject: RFR: 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests In-Reply-To: References: Message-ID: <6CwSUkJVMTcfGGFr5Irs_qHR2jciX3wgV4VU-U9QTJE=.1fbc07ae-fba7-4619-9d69-8cd6dd77bb03@github.com> On Mon, 7 Dec 2020 23:28:20 GMT, David Holmes wrote: > Looks good and trivial. > > Thanks, > David Thank you David! BTW Do you know what the pre-submit failures are about? I think I can ignore those as they look unrelated to this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1678 From gziemski at openjdk.java.net Tue Dec 8 16:24:52 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 8 Dec 2020 16:24:52 GMT Subject: Integrated: 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 21:15:32 GMT, Gerard Ziemski wrote: > This is a workaround for GCC 5.4 bug that is triggered by a particular pattern of math header usage as is the case here with our gtest suite. > > Thank you to Mikael Vidstedt for finding the GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 , triggered by gtest usage as described here https://github.com/google/googletest/commit/fe4d5f10840c5f62b984364a4d41719f1bc079a2 > > Thank you to Ioi for debugging the issue and coming up with the workaround used in this fix. This pull request has now been integrated. Changeset: 936a7acf Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/936a7acf Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1678 From iklam at openjdk.java.net Tue Dec 8 16:48:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 16:48:06 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> Message-ID: On Tue, 8 Dec 2020 10:07:21 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspaceShared.cpp line 1655: >> >>> 1653: archive_space_rs = total_rs.first_part(ccs_begin_offset, >>> 1654: (size_t)os::vm_allocation_granularity(), >>> 1655: /*split=*/false); >> >> Since `/*split=*/false` is passed, the region is no longer split using `os::split_reserved_memory()`. This means on Windows, we cannot use `os::release_memory()` to free the individual regions of `archive_space_rs` and `class_space_rs`. >> >> The Windows API of [VirtualFree](https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree) says: >> >>> Releases the specified region of pages, or placeholder [...], `dwSize` must be 0 (zero), and `lpAddress` must point to the base address returned by the `VirtualAlloc` function when the region is reserved. The function fails if either of these conditions is not met. >> >> I suggest we do this: >> >> - Add an extra `ReservedSpace& total_rs` parameter to `MetaspaceShared::reserve_address_space_for_archives()`. Return the `total_rs` when we go through this path of the code. >> - Also pass `total_rs` to `MetaspaceShared::release_reserved_spaces`. If `total_rs.is_reserverd()` is true, release `total_rs` instead of the two smaller spaces. >> >> To make sure this PR is correct, we should add something like the following in `os::release_memory()`, and check for this log in test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java: >> >> if (!res) { >> log_info(os)("os::release_memory(" PTR_FORMAT ", " SIZE_FORMAT ") failed", p2i(addr), bytes); >> } >> >> Perhaps, in a separate RFE, we should add an assert in `os::release_memory()`, or at least change the `log_info` to `log_warning`. > > Hi Ioi, > > Where is the release you worry about? Since on Windows, since 8255978, os::release_memory() notices if the region the caller wants release does not correspond exactly to a memory mapping at the OS level, and will assert. Do you see that assert? > > I try to understand: > > if useBaseAddress==true, Yumin now creates two separate mappings, and can release them individually > if useBaseAddress==false, there is one mapping as before, but we split now shallow. But we don't release it since we use file IO to read into it. If someone were to release one of those, we should see an assert on Windows. > (I am a tiny bit unhappy about the increasing complexity of the patch, since it negates some of the work done to simplify it back in June.) > > About tracing, since 8256864 we trace Virtualxxx calls, so the tracing is already there - we trace VirtualFree() errrors for "os=info". If you only care for windows, that tracing could suffice. > > Thanks, Thomas If `useBaseAddress==false`, after the total_space is successfully mapped, subsequent operations mail fail. For example, - `mapinfo->map_regions()` may fail to commit the necessary memory for doing `os::read()`. - `mapinfo->validate_shared_path_table()` may fail because the runtime classpath is not compatible In these cases, we need to call MetaspaceShared::release_reserved_spaces(). > Do you see that assert? Hmm, I think we should add a new test for this specifically: `java -XX:ArchiveRelocationMode=1 -cp mispatched.jar` to force the failure in `mapinfo->validate_shared_path_table()`. > If you only care for windows, that tracing could suffice. Since we are changing the `split` parameter for all platforms, I think we should test for all platforms, not just windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From vlivanov at openjdk.java.net Tue Dec 8 17:05:09 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Dec 2020 17:05:09 GMT Subject: Integrated: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: References: Message-ID: <351CI0xzaUx7f58SWmtu5VkMhVVHlp151kh5dKUHzE0=.a5d827e6-12d6-4e33-a37a-9722f0cf04f5@github.com> On Fri, 27 Nov 2020 08:05:09 GMT, Vladimir Ivanov wrote: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html This pull request has now been integrated. Changeset: 044616bd Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/044616bd Stats: 190 lines in 8 files changed: 80 ins; 58 del; 52 mod 8252049: Native memory leak in ciMethodData ctor Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From iklam at openjdk.java.net Tue Dec 8 17:19:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 17:19:12 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> Message-ID: On Tue, 8 Dec 2020 16:45:20 GMT, Ioi Lam wrote: >> Hi Ioi, >> >> Where is the release you worry about? Since on Windows, since 8255978, os::release_memory() notices if the region the caller wants release does not correspond exactly to a memory mapping at the OS level, and will assert. Do you see that assert? >> >> I try to understand: >> >> if useBaseAddress==true, Yumin now creates two separate mappings, and can release them individually >> if useBaseAddress==false, there is one mapping as before, but we split now shallow. But we don't release it since we use file IO to read into it. If someone were to release one of those, we should see an assert on Windows. >> (I am a tiny bit unhappy about the increasing complexity of the patch, since it negates some of the work done to simplify it back in June.) >> >> About tracing, since 8256864 we trace Virtualxxx calls, so the tracing is already there - we trace VirtualFree() errrors for "os=info". If you only care for windows, that tracing could suffice. >> >> Thanks, Thomas > > If `useBaseAddress==false`, after the total_space is successfully mapped, subsequent operations mail fail. For example, > > - `mapinfo->map_regions()` may fail to commit the necessary memory for doing `os::read()`. > - `mapinfo->validate_shared_path_table()` may fail because the runtime classpath is not compatible > > In these cases, we need to call MetaspaceShared::release_reserved_spaces(). > >> Do you see that assert? > > Hmm, I think we should add a new test for this specifically: `java -XX:ArchiveRelocationMode=1 -cp mispatched.jar` to force the failure in `mapinfo->validate_shared_path_table()`. > >> If you only care for windows, that tracing could suffice. > > Since we are changing the `split` parameter for all platforms, I think we should test for all platforms, not just windows. The new test case can be something like this: $ java -XX:DumpLoadedClassList=HelloWorld.classlist -cp HelloWorld.jar HelloWorld Hello World $ java -Xshare:dump -XX:SharedClassListFile=HelloWorld.classlist -cp HelloWorld.jar \ -XX:SharedArchiveFile=tmp.jsa -XX:SharedBaseAddress=0 $ java -Xshare:auto -XX:SharedArchiveFile=tmp.jsa -cp XXX.jar:HelloWorld.jar -Xlog:cds \ -showversion HelloWorld ... [0.034s][info][cds] Archive(s) were created with -XX:SharedBaseAddress=0. Always map at os-selected address. [0.034s][info][cds] Try to map archive(s) at an alternative address [0.034s][info][cds] Mapped static region #0 at base 0x00007f21f7800000 top 0x00007f21f7806000 (MiscCode) [0.034s][info][cds] Mapped static region #1 at base 0x00007f21f7806000 top 0x00007f21f7a1d000 (ReadWrite) [0.034s][info][cds] Mapped static region #2 at base 0x00007f21f7a1d000 top 0x00007f21f7daf000 (ReadOnly) [0.048s][info][cds] UseSharedSpaces: shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) [0.048s][info][cds] Unmapping region #0 at base 0x00007f21f7800000 (MiscCode) [0.048s][info][cds] Unmapping region #1 at base 0x00007f21f7806000 (ReadWrite) [0.048s][info][cds] Unmapping region #2 at base 0x00007f21f7a1d000 (ReadOnly) [0.048s][info][cds] UseSharedSpaces: Unable to map shared spaces java version "16-internal" 2021-03-16 Java(TM) SE Runtime Environment (slowdebug build 16-internal+0-adhoc.iklam.open) Java HotSpot(TM) 64-Bit Server VM (slowdebug build 16-internal+0-adhoc.iklam.open, mixed mode) Hello World You can set a breakpoint at `MetaspaceShared::release_reserved_spaces()` to make sure it's called with `total_rs`. Note that `-Xshare:auto` must be used. If `-Xshare:on` is used, the VM will exit immediately without calling `MetaspaceShared::release_reserved_spaces()`. Most of the CDS tests are executed with `-Xshare:on`. That's why we didn't see the assert on Windows with Yumin's earlier patch -- in Mach5 tier 4, we run test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java with `-XX:ArchiveRelocationMode=1`, but the test itself would use with `-Xshare:on`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From ccheung at openjdk.java.net Tue Dec 8 17:25:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 8 Dec 2020 17:25:13 GMT Subject: RFR: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") Message-ID: Replacing `String s = System.getProperty("user.dir");` with `String s = CDSTestUtils.getOutputDir(); ` Replacing `File dir = new File(System.getProperty("user.dir"));` with `File dir = CDSTestUtils.getOutputDirAsFile();` Passed tier1, hs-tiers 2/3/4 tests. ------------- Commit messages: - 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") Changes: https://git.openjdk.java.net/jdk/pull/1700/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251267 Stats: 59 lines in 24 files changed: 24 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1700/head:pull/1700 PR: https://git.openjdk.java.net/jdk/pull/1700 From minqi at openjdk.java.net Tue Dec 8 18:46:08 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 8 Dec 2020 18:46:08 GMT Subject: RFR: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 17:17:09 GMT, Calvin Cheung wrote: > Replacing > `String s = System.getProperty("user.dir");` > with > `String s = CDSTestUtils.getOutputDir(); ` > > Replacing > `File dir = new File(System.getProperty("user.dir"));` > with > `File dir = CDSTestUtils.getOutputDirAsFile();` > > Passed tier1, hs-tiers 2/3/4 tests. Looks good! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1700 From iklam at openjdk.java.net Tue Dec 8 19:15:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 19:15:54 GMT Subject: RFR: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") In-Reply-To: References: Message-ID: <8VHc3HGu8nYc6LOPrLxiSxCLxdBhT-0xYk32tnhijCY=.5c186af3-efc8-4d6a-8ed2-60c643cf9d4a@github.com> On Tue, 8 Dec 2020 17:17:09 GMT, Calvin Cheung wrote: > Replacing > `String s = System.getProperty("user.dir");` > with > `String s = CDSTestUtils.getOutputDir(); ` > > Replacing > `File dir = new File(System.getProperty("user.dir"));` > with > `File dir = CDSTestUtils.getOutputDirAsFile();` > > Passed tier1, hs-tiers 2/3/4 tests. Looks good to me ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1700 From minqi at openjdk.java.net Tue Dec 8 19:22:37 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 8 Dec 2020 19:22:37 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> Message-ID: On Tue, 8 Dec 2020 17:16:29 GMT, Ioi Lam wrote: >> If `useBaseAddress==false`, after the total_space is successfully mapped, subsequent operations mail fail. For example, >> >> - `mapinfo->map_regions()` may fail to commit the necessary memory for doing `os::read()`. >> - `mapinfo->validate_shared_path_table()` may fail because the runtime classpath is not compatible >> >> In these cases, we need to call MetaspaceShared::release_reserved_spaces(). >> >>> Do you see that assert? >> >> Hmm, I think we should add a new test for this specifically: `java -XX:ArchiveRelocationMode=1 -cp mispatched.jar` to force the failure in `mapinfo->validate_shared_path_table()`. >> >>> If you only care for windows, that tracing could suffice. >> >> Since we are changing the `split` parameter for all platforms, I think we should test for all platforms, not just windows. > > The new test case can be something like this: > > $ java -XX:DumpLoadedClassList=HelloWorld.classlist -cp HelloWorld.jar HelloWorld > Hello World > $ java -Xshare:dump -XX:SharedClassListFile=HelloWorld.classlist -cp HelloWorld.jar \ > -XX:SharedArchiveFile=tmp.jsa -XX:SharedBaseAddress=0 > $ touch XXX.jar > $ java -Xshare:auto -XX:SharedArchiveFile=tmp.jsa -cp XXX.jar:HelloWorld.jar -Xlog:cds \ > -showversion HelloWorld > ... > [0.034s][info][cds] Archive(s) were created with -XX:SharedBaseAddress=0. Always map at os-selected address. > [0.034s][info][cds] Try to map archive(s) at an alternative address > [0.034s][info][cds] Mapped static region #0 at base 0x00007f21f7800000 top 0x00007f21f7806000 (MiscCode) > [0.034s][info][cds] Mapped static region #1 at base 0x00007f21f7806000 top 0x00007f21f7a1d000 (ReadWrite) > [0.034s][info][cds] Mapped static region #2 at base 0x00007f21f7a1d000 top 0x00007f21f7daf000 (ReadOnly) > [0.048s][info][cds] UseSharedSpaces: shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) > [0.048s][info][cds] Unmapping region #0 at base 0x00007f21f7800000 (MiscCode) > [0.048s][info][cds] Unmapping region #1 at base 0x00007f21f7806000 (ReadWrite) > [0.048s][info][cds] Unmapping region #2 at base 0x00007f21f7a1d000 (ReadOnly) > [0.048s][info][cds] UseSharedSpaces: Unable to map shared spaces > java version "16-internal" 2021-03-16 > Java(TM) SE Runtime Environment (slowdebug build 16-internal+0-adhoc.iklam.open) > Java HotSpot(TM) 64-Bit Server VM (slowdebug build 16-internal+0-adhoc.iklam.open, mixed mode) > Hello World > You can set a breakpoint at `MetaspaceShared::release_reserved_spaces()` to make sure it's called with `total_rs`. > > Note that `-Xshare:auto` must be used. > > If `-Xshare:on` is used, the VM will exit immediately without calling `MetaspaceShared::release_reserved_spaces()`. Most of the CDS tests are executed with `-Xshare:on`. That's why we didn't see the assert on Windows with Yumin's earlier patch -- in Mach5 tier 4, we run test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java with `-XX:ArchiveRelocationMode=1`, but the test itself would use with `-Xshare:on`. When jar mismatched, say, -cp non-exist.jar (We could not use -cp no-exitst.jar:hello.jar since, once hello.jar the dump time jar found and matched, the non-exist.jar will be ignored, test showed it is OK), the output: [0.035s][info ][cds] Mapped static region #0 at base 0x00007f98e3800000 top 0x00007f98e3806000 (MiscCode) [0.035s][info ][cds] Mapped static region #1 at base 0x00007f98e3806000 top 0x00007f98e3a1e000 (ReadWrite) [0.035s][info ][cds] Mapped static region #2 at base 0x00007f98e3a1e000 top 0x00007f98e3db2000 (ReadOnly) [0.049s][info ][cds] UseSharedSpaces: shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) [0.049s][info ][cds] Unmapping region #0 at base 0x00007f98e3800000 (MiscCode) [0.049s][info ][cds] Unmapping region #1 at base 0x00007f98e3806000 (ReadWrite) [0.049s][info ][cds] Unmapping region #2 at base 0x00007f98e3a1e000 (ReadOnly) [0.049s][debug][cds] Released shared space 0x00007f98e3800000 [0.049s][debug][cds] Released shared space (archive + class) 0x00007f98e3800000 [0.049s][info ][cds] UseSharedSpaces: Unable to map shared spaces The repeat will be eliminated next version from here: 1489 } else { 1490 unmap_archive(static_mapinfo); 1491 unmap_archive(dynamic_mapinfo); 1492 log_debug(cds)("Released shared space " INTPTR_FORMAT, p2i(total_space_rs.base())); 1493 release_reserved_spaces(total_space_rs, archive_space_rs, class_space_rs); 1494 } ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From iklam at openjdk.java.net Tue Dec 8 20:02:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 20:02:33 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v4] In-Reply-To: References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com> <1VLLRFiHXlE0kjIPDO0JOeJmhTf-KCkOC9BiyjRgC4A=.6c4a0286-5dda-4e27-a7f3-4479b5c464c5@github.com> Message-ID: <_M1sQtz4u6Q9_MLDdjt5ucxq9AA0Lz5ftD2ih78AjP8=.9ec7dbb5-f3de-420c-b5ab-870b4e1b06a2@github.com> On Tue, 8 Dec 2020 19:20:17 GMT, Yumin Qi wrote: >> The new test case can be something like this: >> >> $ java -XX:DumpLoadedClassList=HelloWorld.classlist -cp HelloWorld.jar HelloWorld >> Hello World >> $ java -Xshare:dump -XX:SharedClassListFile=HelloWorld.classlist -cp HelloWorld.jar \ >> -XX:SharedArchiveFile=tmp.jsa -XX:SharedBaseAddress=0 >> $ touch XXX.jar >> $ java -Xshare:auto -XX:SharedArchiveFile=tmp.jsa -cp XXX.jar:HelloWorld.jar -Xlog:cds \ >> -showversion HelloWorld >> ... >> [0.034s][info][cds] Archive(s) were created with -XX:SharedBaseAddress=0. Always map at os-selected address. >> [0.034s][info][cds] Try to map archive(s) at an alternative address >> [0.034s][info][cds] Mapped static region #0 at base 0x00007f21f7800000 top 0x00007f21f7806000 (MiscCode) >> [0.034s][info][cds] Mapped static region #1 at base 0x00007f21f7806000 top 0x00007f21f7a1d000 (ReadWrite) >> [0.034s][info][cds] Mapped static region #2 at base 0x00007f21f7a1d000 top 0x00007f21f7daf000 (ReadOnly) >> [0.048s][info][cds] UseSharedSpaces: shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) >> [0.048s][info][cds] Unmapping region #0 at base 0x00007f21f7800000 (MiscCode) >> [0.048s][info][cds] Unmapping region #1 at base 0x00007f21f7806000 (ReadWrite) >> [0.048s][info][cds] Unmapping region #2 at base 0x00007f21f7a1d000 (ReadOnly) >> [0.048s][info][cds] UseSharedSpaces: Unable to map shared spaces >> java version "16-internal" 2021-03-16 >> Java(TM) SE Runtime Environment (slowdebug build 16-internal+0-adhoc.iklam.open) >> Java HotSpot(TM) 64-Bit Server VM (slowdebug build 16-internal+0-adhoc.iklam.open, mixed mode) >> Hello World >> You can set a breakpoint at `MetaspaceShared::release_reserved_spaces()` to make sure it's called with `total_rs`. >> >> Note that `-Xshare:auto` must be used. >> >> If `-Xshare:on` is used, the VM will exit immediately without calling `MetaspaceShared::release_reserved_spaces()`. Most of the CDS tests are executed with `-Xshare:on`. That's why we didn't see the assert on Windows with Yumin's earlier patch -- in Mach5 tier 4, we run test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java with `-XX:ArchiveRelocationMode=1`, but the test itself would use with `-Xshare:on`. > > When jar mismatched, say, -cp non-exist.jar (We could not use -cp no-exitst.jar:hello.jar since, once hello.jar the dump time jar found and matched, the non-exist.jar will be ignored, test showed it is OK), the output: > [0.035s][info ][cds] Mapped static region #0 at base 0x00007f98e3800000 top 0x00007f98e3806000 (MiscCode) > [0.035s][info ][cds] Mapped static region #1 at base 0x00007f98e3806000 top 0x00007f98e3a1e000 (ReadWrite) > [0.035s][info ][cds] Mapped static region #2 at base 0x00007f98e3a1e000 top 0x00007f98e3db2000 (ReadOnly) > [0.049s][info ][cds] UseSharedSpaces: shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) > [0.049s][info ][cds] Unmapping region #0 at base 0x00007f98e3800000 (MiscCode) > [0.049s][info ][cds] Unmapping region #1 at base 0x00007f98e3806000 (ReadWrite) > [0.049s][info ][cds] Unmapping region #2 at base 0x00007f98e3a1e000 (ReadOnly) > [0.049s][debug][cds] Released shared space 0x00007f98e3800000 > [0.049s][debug][cds] Released shared space (archive + class) 0x00007f98e3800000 > [0.049s][info ][cds] UseSharedSpaces: Unable to map shared spaces > > The repeat will be eliminated next version from here: > 1489 } else { > 1490 unmap_archive(static_mapinfo); > 1491 unmap_archive(dynamic_mapinfo); > 1492 log_debug(cds)("Released shared space " INTPTR_FORMAT, p2i(total_space_rs.base())); > 1493 release_reserved_spaces(total_space_rs, archive_space_rs, class_space_rs); > 1494 } You're correct that if you use `-cp non-exist.jar:hello.jar`, the non-exist.jar will be ignored because it doesn't exist, and CDS will not treat the classpath as a mismatch. However, in my example, I created the XXX.jar file, so CDS will treat the classpath as a mismatch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1657 From ccheung at openjdk.java.net Tue Dec 8 20:03:37 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 8 Dec 2020 20:03:37 GMT Subject: Integrated: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 17:17:09 GMT, Calvin Cheung wrote: > Replacing > `String s = System.getProperty("user.dir");` > with > `String s = CDSTestUtils.getOutputDir(); ` > > Replacing > `File dir = new File(System.getProperty("user.dir"));` > with > `File dir = CDSTestUtils.getOutputDirAsFile();` > > Passed tier1, hs-tiers 2/3/4 tests. This pull request has now been integrated. Changeset: 291ba97f Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/291ba97f Stats: 59 lines in 24 files changed: 24 ins; 0 del; 35 mod 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") Reviewed-by: minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1700 From ccheung at openjdk.java.net Tue Dec 8 20:03:36 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 8 Dec 2020 20:03:36 GMT Subject: RFR: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir") In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 18:43:08 GMT, Yumin Qi wrote: >> Replacing >> `String s = System.getProperty("user.dir");` >> with >> `String s = CDSTestUtils.getOutputDir(); ` >> >> Replacing >> `File dir = new File(System.getProperty("user.dir"));` >> with >> `File dir = CDSTestUtils.getOutputDirAsFile();` >> >> Passed tier1, hs-tiers 2/3/4 tests. > > Looks good! @yminqi, @iklam, thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1700 From mr at openjdk.java.net Tue Dec 8 22:15:40 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 8 Dec 2020 22:15:40 GMT Subject: Integrated: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. This pull request has now been integrated. Changeset: ed4c4ee7 Author: Mark Reinhold URL: https://git.openjdk.java.net/jdk/commit/ed4c4ee7 Stats: 162 lines in 5 files changed: 24 ins; 73 del; 65 mod 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default Co-authored-by: Alan Bateman Reviewed-by: mchung, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From ksakata at openjdk.java.net Tue Dec 8 23:59:54 2020 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Tue, 8 Dec 2020 23:59:54 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options [v2] In-Reply-To: References: Message-ID: > In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). > But it?s possible to specify options with more colons like `java -Xlog:::::`. > It?s better to show a message when more options are specified than maximum number. > > By this PR a warning message is outputted when options are specified more than the max number. Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: Change the warning message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1685/files - new: https://git.openjdk.java.net/jdk/pull/1685/files/e5ab2837..ed882ea4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1685&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1685&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1685/head:pull/1685 PR: https://git.openjdk.java.net/jdk/pull/1685 From ksakata at openjdk.java.net Wed Dec 9 00:09:39 2020 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Wed, 9 Dec 2020 00:09:39 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options [v2] In-Reply-To: <-aCSMWn3fc0CpNpCNdc8w0kiKm2C07qLkNpLhKNV9u4=.5e81a884-07b8-4896-9422-3120b2e32238@github.com> References: <-aCSMWn3fc0CpNpCNdc8w0kiKm2C07qLkNpLhKNV9u4=.5e81a884-07b8-4896-9422-3120b2e32238@github.com> Message-ID: On Tue, 8 Dec 2020 06:13:18 GMT, David Holmes wrote: >> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: >> >> Change the warning message > > src/hotspot/share/logging/logConfiguration.cpp line 371: > >> 369: >> 370: if (str != NULL) { >> 371: log_warning(logging)("Options are specified more than the max number in -Xlog."); > > Might I suggest: > `log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);` Thank you for your suggestion. This message is clear for everyone. I changed the warning message. ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From mchung at openjdk.java.net Wed Dec 9 00:43:34 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Dec 2020 00:43:34 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with Record attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Remi, > It's not an issue, the JVM view of what a record is and the JLS view of what a record is doesn't have to be identical, > only aligned. It's fine for the VM to consider any class that have a record Attribute is a record. > > We already had this discussion on amber-spec-expert list, > see https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html What is the conclusion (sorry it was unclear to me)? Drop TNSFF for records? This issue is to fix the regression introduced by JDK-8255342. I expect someone else will file a new JBS issue and implement what amber-spec-experts decided. > We already know that the JLS definition of a record will have to be changed for inline record (an inline record is not direct subclass of j.l.Record because you have the reference projection in the middle). Yes I saw that. I updated [JDK-8251041](https://bugs.openjdk.java.net/browse/JDK-8251041) to follow up. > The real issue is that the JIT optimisation and Field.set() should be aligned, VarHandle deosn't let you change a final field and Unsafe is unsafe, so the current problem is that Field.set() relies on the reflection api by calling Class.isRecord() which is not good because Classs.isRecord() returns the JLS view of the world not the JVM view of the world. > > As said in the mail chain above, for the JIT optimization, instead of listing all the new constructs, record, inline, etc, i propose to check the other way, only allow to set a final field is only allowed for plain old java class, so the VM should not have a method InstanceKlass::is_record but a method that return if a class is a plain class or not and this method should be called by the JIT and by Field.set (through a JVM entry point) > so the fact the optimization will be done or not is not related to what the JLS think a record is, those are separated concern. I agree the current situation is not ideal which requires to declare all the new constructs explicitly for TNSFF. However, it's a reasonable tradeoff to get the JIT optimization for records in time while waiting for true TNSFF investigation like JMM and other relevant specs. I see this just a stop-gap solution. When the long-term TNSFF is in place, the spec can be updated to drop the explicit list of record, inline, etc. A related issue is [JDK-8233873](https://bugs.openjdk.java.net/browse/JDK-8233873). I'm happy if we can do TNSFF in a different solution. Again this PR intends to fix the regression. Two options: 1. Keep [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) and implement as this proposed patch 2. Backout [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) I expect Chris and/or others will follow up the decision made by the amber-spec-experts w.r.t. trusting finals in records. I'm okay with either option. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From iklam at openjdk.java.net Wed Dec 9 01:02:38 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Dec 2020 01:02:38 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 03:02:03 GMT, Koichi Sakata wrote: > In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). > But it?s possible to specify options with more colons like `java -Xlog:::::`. > It?s better to show a message when more options are specified than maximum number. > > By this PR a warning message is outputted when options are specified more than the max number. Should this be a warning or an error? The behavior seems inconsistent: $ java -Xlog:gc=error:::foo -version [0.000s][warning][logging] Output options for existing outputs are ignored. java version "16-internal" 2021-03-16 Java(TM) SE Runtime Environment (build 16-internal+0-adhoc.iklam.open) Java HotSpot(TM) 64-Bit Server VM (build 16-internal+0-adhoc.iklam.open, mixed mode, sharing) $ java -Xlog:gc=error::foo -version [0.000s][error][logging] Invalid decorator 'foo'. Invalid -Xlog option '-Xlog:gc=error::foo', see error log for details. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From ksakata at openjdk.java.net Wed Dec 9 03:07:34 2020 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Wed, 9 Dec 2020 03:07:34 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options In-Reply-To: References: Message-ID: <4RuevvWTrCkdVHfKXsaOnWuu3ezNTeUVjRqzE98kyFw=.072aec2d-8dde-424f-9659-492e747b6753@github.com> On Wed, 9 Dec 2020 00:59:56 GMT, Ioi Lam wrote: >> In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). >> But it?s possible to specify options with more colons like `java -Xlog:::::`. >> It?s better to show a message when more options are specified than maximum number. >> >> By this PR a warning message is outputted when options are specified more than the max number. > > Should this be a warning or an error? The behavior seems inconsistent: > > $ java -Xlog:gc=error:::foo -version > [0.000s][warning][logging] Output options for existing outputs are ignored. > java version "16-internal" 2021-03-16 > Java(TM) SE Runtime Environment (build 16-internal+0-adhoc.iklam.open) > Java HotSpot(TM) 64-Bit Server VM (build 16-internal+0-adhoc.iklam.open, mixed mode, sharing) > > $ java -Xlog:gc=error::foo -version > [0.000s][error][logging] Invalid decorator 'foo'. > Invalid -Xlog option '-Xlog:gc=error::foo', see error log for details. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. In this PR I chose a warning level to ignore the invalid option and run a application. It isn't serious thing and some people might run with invalid option already. The fourth option is for output-option and can be described relatively free. So I suspect that it is ignored even when it is invalid. ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From jiefu at openjdk.java.net Wed Dec 9 09:04:32 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 9 Dec 2020 09:04:32 GMT Subject: Integrated: 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 03:25:10 GMT, Jie Fu wrote: > Hi all, > > Zero debug build on Linux/x86_32 is broken due to an incorrect assert [1]. > > 'istate->_stack_limit' is set here [2] as 'stack->sp() - 1'. > 'istate->_thread->last_Java_sp()' is set here [3], which is actually 'stack->sp()' according to [4]. > > So the correct assert should be: > assert(istate->_stack_limit == istate->_thread->last_Java_sp() - 1) > > It would be better to fix it. > > Testing: > - Zero fastdebug build passed on Linux/x86_32 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L422 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L819 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/zero/zeroInterpreter_zero.cpp#L194 > [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_zero/thread_linux_zero.hpp#L65 This pull request has now been integrated. Changeset: df55ecd8 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/df55ecd8 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8257794: Zero: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1) failed: wrong on Linux/x86_32 Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1637 From mdoerr at openjdk.java.net Wed Dec 9 10:01:32 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 9 Dec 2020 10:01:32 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: <47M-vg5eZzZ3Yp9xnk1cvobVdXMfQp4daySSTd8kMbk=.29911641-7483-49d8-bfb7-e39df7880a9b@github.com> On Tue, 8 Dec 2020 13:35:24 GMT, Thomas Stuefe wrote: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas Thank you for fixing it! Good that we have signals_posix.cpp, now. Seems like os::min_page_size() is an address which is not readable on any OS we have. So test looks also good to me. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From tschatzl at openjdk.java.net Wed Dec 9 10:54:49 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 10:54:49 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap Message-ID: Hi all, can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. There some points I would like to bring up in advance in this change that may be contentious: - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) ------------- Commit messages: - Initial import Changes: https://git.openjdk.java.net/jdk/pull/1661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1661&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256641 Stats: 132 lines in 10 files changed: 84 ins; 30 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1661/head:pull/1661 PR: https://git.openjdk.java.net/jdk/pull/1661 From kbarrett at openjdk.java.net Wed Dec 9 12:27:36 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 12:27:36 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: References: Message-ID: <1NlD3pEuvW66ocFsjP9la5yjKfsLN6hmtMee8-ZafPM=.d3db39ce-730e-46e6-9124-297ccdd2cc2f@github.com> On Mon, 7 Dec 2020 11:23:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. > > There some points I would like to bring up in advance in this change that may be contentious: > - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. > - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/shared/gcVMOperations.cpp line 64: > 62: > 63: void VM_GC_Sync_Operation::doit_epilogue() { > 64: if (Universe::has_reference_pending_list()) { Why is the pending list handling moved here, rather than remaining in VM_GC_Operation::doit_epilogue? This doesn't have anything to do with syncing between operations, and seems odd for VM_Verify (for example) to do. src/hotspot/share/gc/shared/gcVMOperations.cpp line 61: > 59: } > 60: return _prologue_succeeded; > 61: } This invocation checking doesn't seem right at this level. That is, skip_operation and prologue_succeeded all seem to me to have nothing to do with syncing, instead belonging to the VM_GC_Operation level and should remain there. src/hotspot/share/gc/shared/gcVMOperations.hpp line 103: > 101: // Acquire the reference synchronization lock > 102: virtual bool doit_prologue(); > 103: // Do notifyAll (if needed) and release held lock s/notifyAll/notify_all/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From tschatzl at openjdk.java.net Wed Dec 9 12:31:34 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 12:31:34 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: <1NlD3pEuvW66ocFsjP9la5yjKfsLN6hmtMee8-ZafPM=.d3db39ce-730e-46e6-9124-297ccdd2cc2f@github.com> References: <1NlD3pEuvW66ocFsjP9la5yjKfsLN6hmtMee8-ZafPM=.d3db39ce-730e-46e6-9124-297ccdd2cc2f@github.com> Message-ID: <6nH7SZYCYVXMHQaONxFh2OAZzhby9pQmyfuHVx-m69c=.f77113b7-84d5-45e6-8fa8-9ad628534f43@github.com> On Wed, 9 Dec 2020 11:58:46 GMT, Kim Barrett wrote: >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. >> - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > src/hotspot/share/gc/shared/gcVMOperations.cpp line 64: > >> 62: >> 63: void VM_GC_Sync_Operation::doit_epilogue() { >> 64: if (Universe::has_reference_pending_list()) { > > Why is the pending list handling moved here, rather than remaining in VM_GC_Operation::doit_epilogue? This doesn't have anything to do with syncing between operations, and seems odd for VM_Verify (for example) to do. Also answering the next question: these two items (i.e. including the `prologue_succeeded` stuff) have mostly been kept there to allow simple reuse in `VM_GC_Operation`. I'll remove those and (maybe) just break the inheritance chain. ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From tschatzl at openjdk.java.net Wed Dec 9 13:19:46 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 13:19:46 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. > > There some points I would like to bring up in advance in this change that may be contentious: > - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. > - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1661/files - new: https://git.openjdk.java.net/jdk/pull/1661/files/1b5b5a8d..213fbeed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1661&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1661&range=00-01 Stats: 56 lines in 2 files changed: 15 ins; 20 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1661/head:pull/1661 PR: https://git.openjdk.java.net/jdk/pull/1661 From kbarrett at openjdk.java.net Wed Dec 9 14:07:35 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 14:07:35 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: <4NLyVkBh3WaB8Hh-78Ta-dpq2JMzGrdM6IqW_NG_SBQ=.e0b77b19-c2e5-4dd0-96ca-8ac5e7e09c00@github.com> On Tue, 8 Dec 2020 13:35:24 GMT, Thomas Stuefe wrote: > if (info != NULL && uc != NULL && thread != NULL) { So the cause of the problem is the `thread != NULL` in that test. And just removing all of those would fix the problem. But I agree that eliminating all the (near) copied variants and merging this functionality into signals_posix is good. > This is unfortunate since SafeFetch is used [...] Another place this hits is OopStorage, which uses SafeFetchN in two places. Correct code shouldn't have a problem with one of them because the access won't be invalid (if code is correct). But the other could be a problem, though I think not seen in practice. Might there be any similar problem on Windows? This might be kind of related? https://bugs.openjdk.java.net/browse/JDK-8185734 ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From coleenp at openjdk.java.net Wed Dec 9 14:36:37 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 14:36:37 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 13:35:24 GMT, Thomas Stuefe wrote: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas This looks good to me. Moving this to the posix signal handler is so nice. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From kbarrett at openjdk.java.net Wed Dec 9 15:58:38 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 15:58:38 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v2] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:19:46 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. >> - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Code changes look good. A couple of places where comments could use some improvement. src/hotspot/share/gc/shared/gcVMOperations.hpp line 146: > 144: > 145: // Acquire the reference synchronization lock > 146: virtual bool doit_prologue(); This does a lot more than just acquiring the lock. It also handles the prevention of multiple gc requests. src/hotspot/share/gc/shared/gcVMOperations.hpp line 111: > 109: protected: > 110: uint _gc_count_before; // gc count before acquiring PLL > 111: uint _full_gc_count_before; // full gc count before acquiring PLL [pre-existing] "PLL" ? I think that might be obsolete terminology, referring to the "pending list lock"? I think should be Heap_lock now. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1661 From coleenp at openjdk.java.net Wed Dec 9 16:39:39 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 16:39:39 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Message-ID: This change handles redefinition during method resolution, but returning the new method. It's not needed to reresolve the invocation. See the bug for more information. Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. ------------- Commit messages: - 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Changes: https://git.openjdk.java.net/jdk/pull/1717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1717&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245446 Stats: 22 lines in 1 file changed: 2 ins; 12 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1717/head:pull/1717 PR: https://git.openjdk.java.net/jdk/pull/1717 From sspitsyn at openjdk.java.net Wed Dec 9 17:23:33 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 9 Dec 2020 17:23:33 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, but returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. Hi Coleen, I like this fix and looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 18:25:52 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 18:25:52 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 17:21:16 GMT, Serguei Spitsyn wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. >> >> I don't now why it can't link to the issue: >> https://bugs.openjdk.java.net/browse/JDK-8245446 > > Hi Coleen, > I like this fix and looks good. > Thanks, > Serguei Thanks Serguei for the fast review and discussion about this bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From iklam at openjdk.java.net Wed Dec 9 18:26:48 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Dec 2020 18:26:48 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v2] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:19:46 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. >> - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review The CDS part looks good to me. I also scanned the GC code and it looks reasonable to me, but I don't understand all the details to give an official review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:26:52 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:26:52 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> On Mon, 7 Dec 2020 08:52:28 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include (ppc,s390 builds failed) test/hotspot/gtest/runtime/test_os.cpp line 104: > 102: const size_t expected = os::page_sizes().next_smaller(s); > 103: if (expected != 0) { > 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); @tstuefe should **expected** here be **s** ? It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. `os::page_size_for_region_unaligned(expected - 17, 1);` vs. `os::page_size_for_region_unaligned(s - 17, 1);` Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) > [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: a ctual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:30:38 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:30:38 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> Message-ID: <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> On Wed, 9 Dec 2020 17:26:43 GMT, Marcus G K Williams wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include (ppc,s390 builds failed) > > test/hotspot/gtest/runtime/test_os.cpp line 104: > >> 102: const size_t expected = os::page_sizes().next_smaller(s); >> 103: if (expected != 0) { >> 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); > > @tstuefe should **expected** here be **s** ? > > It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. > > `os::page_size_for_region_unaligned(expected - 17, 1);` > vs. > `os::page_size_for_region_unaligned(s - 17, 1);` > > Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): > (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) > > This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. See https://github.com/openjdk/jdk/pull/1719 for fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:37:39 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:37:39 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask Message-ID: <6JyG2rAdIyn6NErdfpw4CB1_egFsVLKrg1BDognboFo=.07cfb4d7-ba5b-4bb9-bae5-696edb56c00c@github.com> There appears to be a bug at ln105 of test/hotspot/gtest/runtime/test_os.cpp https://github.com/openjdk/jdk/pull/1522/files/163b308b97c07d567c48f100475481cdc5e75740#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884R104 ` // Given a slightly smaller size than a page size, // return the next smaller page size. if (os::_page_sizes[1] > os::_page_sizes[0]) { size_t expected = os::_page_sizes[0]; size_t actual = os::page_size_for_region_unaligned(os::_page_sizes[1] - 17, 1); ASSERT_EQ(actual, expected); for (size_t s = os::page_sizes().largest(); s != 0; s = os::page_sizes().next_smaller(s)) { const size_t expected = os::page_sizes().next_smaller(s); if (expected != 0) { size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); ASSERT_EQ(actual, expected); } }` On ln104 we are trying to compare the next smaller page size of 's', with a page size returned for slightly smaller size of the size 's -17'. Instead we compare next smaller page size of 's' to 'expected - 17'. I believe this should be 's - 17': `os::page_size_for_region_unaligned(expected - 17, 1);` vs. `os::page_size_for_region_unaligned(s - 17, 1);` Running gtest tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) > [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: a ctual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. Signed-off-by: Marcus G K Williams ------------- Commit messages: - JDK-8257588: Fix bug @ ln104 Changes: https://git.openjdk.java.net/jdk/pull/1719/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1719&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257588 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1719/head:pull/1719 PR: https://git.openjdk.java.net/jdk/pull/1719 From stuefe at openjdk.java.net Wed Dec 9 18:46:38 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 18:46:38 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> Message-ID: On Wed, 9 Dec 2020 18:27:30 GMT, Marcus G K Williams wrote: >> test/hotspot/gtest/runtime/test_os.cpp line 104: >> >>> 102: const size_t expected = os::page_sizes().next_smaller(s); >>> 103: if (expected != 0) { >>> 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); >> >> @tstuefe should **expected** here be **s** ? >> >> It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. >> >> `os::page_size_for_region_unaligned(expected - 17, 1);` >> vs. >> `os::page_size_for_region_unaligned(s - 17, 1);` >> >> Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): >> (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >>> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) >> >> This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. > > See https://github.com/openjdk/jdk/pull/1719 for fix. Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Wed Dec 9 18:46:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 18:46:39 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> Message-ID: <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> On Wed, 9 Dec 2020 18:39:15 GMT, Thomas Stuefe wrote: >> See https://github.com/openjdk/jdk/pull/1719 for fix. > > Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. > > Thanks, Thomas Oh, I see you already have a PR open, I reply there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:46:40 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:46:40 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> Message-ID: On Wed, 9 Dec 2020 18:41:32 GMT, Thomas Stuefe wrote: >> Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. >> >> Thanks, Thomas > > Oh, I see you already have a PR open, I reply there. Fixed in #1719. Thanks Thomas. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Wed Dec 9 18:47:38 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 18:47:38 GMT Subject: RFR: JDK-8257989: Error in gtest os_page_size_for_region_unaligned after 8257588 In-Reply-To: <6JyG2rAdIyn6NErdfpw4CB1_egFsVLKrg1BDognboFo=.07cfb4d7-ba5b-4bb9-bae5-696edb56c00c@github.com> References: <6JyG2rAdIyn6NErdfpw4CB1_egFsVLKrg1BDognboFo=.07cfb4d7-ba5b-4bb9-bae5-696edb56c00c@github.com> Message-ID: On Wed, 9 Dec 2020 18:26:32 GMT, Marcus G K Williams wrote: > There appears to be a bug at ln105 of test/hotspot/gtest/runtime/test_os.cpp > > https://github.com/openjdk/jdk/pull/1522/files/163b308b97c07d567c48f100475481cdc5e75740#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884R104 > > ` // Given a slightly smaller size than a page size, > // return the next smaller page size. > if (os::_page_sizes[1] > os::_page_sizes[0]) { > size_t expected = os::_page_sizes[0]; > size_t actual = os::page_size_for_region_unaligned(os::_page_sizes[1] - 17, 1); > ASSERT_EQ(actual, expected); > for (size_t s = os::page_sizes().largest(); s != 0; s = os::page_sizes().next_smaller(s)) { > const size_t expected = os::page_sizes().next_smaller(s); > if (expected != 0) { > size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); > ASSERT_EQ(actual, expected); > } > }` > > On ln104 we are trying to compare the next smaller page size of 's', with a page size returned for slightly smaller size of the size 's -17'. > > Instead we compare next smaller page size of 's' to 'expected - 17'. I believe this should be 's - 17': > `os::page_size_for_region_unaligned(expected - 17, 1);` > vs. > `os::page_size_for_region_unaligned(s - 17, 1);` > > Running gtest tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): > (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) > > This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. > > Signed-off-by: Marcus G K Williams LGTM. Thanks for finding this! Hi, Fix makes sense and is trivial. I opened https://bugs.openjdk.java.net/browse/JDK-8257989 for this. ("Trivial" means only needs one reviewer and can be integrated right away without waiting the obligatory 24hrs). But please change the title of the PR to "JDK-8257989: Error in gtest os_page_size_for_region_unaligned after 8257588" before pushing, otherwise skara gets confused. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1719 From hseigel at openjdk.java.net Wed Dec 9 18:47:38 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 9 Dec 2020 18:47:38 GMT Subject: RFR: 8245446: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > I don't now why it can't link to the issue: > https://bugs.openjdk.java.net/browse/JDK-8245446 The changes look good! ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 19:02:36 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 19:02:36 GMT Subject: Integrated: JDK-8257989: Error in gtest os_page_size_for_region_unaligned after 8257588 In-Reply-To: <6JyG2rAdIyn6NErdfpw4CB1_egFsVLKrg1BDognboFo=.07cfb4d7-ba5b-4bb9-bae5-696edb56c00c@github.com> References: <6JyG2rAdIyn6NErdfpw4CB1_egFsVLKrg1BDognboFo=.07cfb4d7-ba5b-4bb9-bae5-696edb56c00c@github.com> Message-ID: On Wed, 9 Dec 2020 18:26:32 GMT, Marcus G K Williams wrote: > There appears to be a bug at ln105 of test/hotspot/gtest/runtime/test_os.cpp > > https://github.com/openjdk/jdk/pull/1522/files/163b308b97c07d567c48f100475481cdc5e75740#diff-6d3fc66964a0fccf7f85c284fffec5dffa62be8497423a7684cee83d55338884R104 > > ` // Given a slightly smaller size than a page size, > // return the next smaller page size. > if (os::_page_sizes[1] > os::_page_sizes[0]) { > size_t expected = os::_page_sizes[0]; > size_t actual = os::page_size_for_region_unaligned(os::_page_sizes[1] - 17, 1); > ASSERT_EQ(actual, expected); > for (size_t s = os::page_sizes().largest(); s != 0; s = os::page_sizes().next_smaller(s)) { > const size_t expected = os::page_sizes().next_smaller(s); > if (expected != 0) { > size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); > ASSERT_EQ(actual, expected); > } > }` > > On ln104 we are trying to compare the next smaller page size of 's', with a page size returned for slightly smaller size of the size 's -17'. > > Instead we compare next smaller page size of 's' to 'expected - 17'. I believe this should be 's - 17': > `os::page_size_for_region_unaligned(expected - 17, 1);` > vs. > `os::page_size_for_region_unaligned(s - 17, 1);` > > Running gtest tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): > (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) > > This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. > > Signed-off-by: Marcus G K Williams This pull request has now been integrated. Changeset: b977a7b8 Author: Marcus G K Williams Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/b977a7b8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257989: Error in gtest os_page_size_for_region_unaligned after 8257588 Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1719 From coleenp at openjdk.java.net Wed Dec 9 20:20:37 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 20:20:37 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <_0dKUIp1fWZXTUq_TJJha3XhR21nIkp0TOzAtCv1cSY=.4c6cea7f-936f-4487-ad80-fd8ed9d13cb6@github.com> On Wed, 9 Dec 2020 18:44:37 GMT, Harold Seigel wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > The changes look good! Thank you Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From iklam at openjdk.java.net Wed Dec 9 23:05:36 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Dec 2020 23:05:36 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v2] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 13:19:46 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. >> - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From dholmes at openjdk.java.net Wed Dec 9 23:13:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Dec 2020 23:13:32 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 23:13:32 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 23:13:32 GMT Subject: RFR: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <8iH1btiJXh6bSEgZ02snEfnXSI1mNEhYX9xHgsJIANU=.457564db-87e4-4323-a6b2-3ea9751bcdcb@github.com> On Wed, 9 Dec 2020 23:06:38 GMT, David Holmes wrote: >> This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. >> >> Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. > > Looks good. > Thanks, > David Thanks David. ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From coleenp at openjdk.java.net Wed Dec 9 23:13:33 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 23:13:33 GMT Subject: Integrated: 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently In-Reply-To: References: Message-ID: <9MYa0NE3pM_ytBR-YvDvO19ET4mxHRuCX4kQIAyaSN0=.5fdda13e-7598-4f95-93e0-c26f8d50e7e3@github.com> On Wed, 9 Dec 2020 16:33:22 GMT, Coleen Phillimore wrote: > This change handles redefinition during method resolution, by returning the new method. It's not needed to reresolve the invocation. See the bug for more information. > > Tested with tier1-3 and tier8 on linux-x64-debug and macos-x64-debug, and running the failing tests 100x without failure. Thank you to Serguei for confirming the testing. This pull request has now been integrated. Changeset: 0a3e446a Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/0a3e446a Stats: 22 lines in 1 file changed: 2 ins; 12 del; 8 mod 8257993: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently Reviewed-by: sspitsyn, hseigel, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1717 From dholmes at openjdk.java.net Thu Dec 10 01:43:39 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Dec 2020 01:43:39 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 23:59:54 GMT, Koichi Sakata wrote: >> In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). >> But it?s possible to specify options with more colons like `java -Xlog:::::`. >> It?s better to show a message when more options are specified than maximum number. >> >> By this PR a warning message is outputted when options are specified more than the max number. > > Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: > > Change the warning message Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From dholmes at openjdk.java.net Thu Dec 10 01:43:39 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Dec 2020 01:43:39 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options In-Reply-To: <4RuevvWTrCkdVHfKXsaOnWuu3ezNTeUVjRqzE98kyFw=.072aec2d-8dde-424f-9659-492e747b6753@github.com> References: <4RuevvWTrCkdVHfKXsaOnWuu3ezNTeUVjRqzE98kyFw=.072aec2d-8dde-424f-9659-492e747b6753@github.com> Message-ID: <-EvOtMzt0xY1pO9zHwgTJaaYVgebVH4-tIHsZePnRuE=.e0496933-0061-4742-99ba-4010e6fa95cf@github.com> On Wed, 9 Dec 2020 03:04:32 GMT, Koichi Sakata wrote: >> Should this be a warning or an error? The behavior seems inconsistent: >> >> $ java -Xlog:gc=error:::foo -version >> [0.000s][warning][logging] Output options for existing outputs are ignored. >> java version "16-internal" 2021-03-16 >> Java(TM) SE Runtime Environment (build 16-internal+0-adhoc.iklam.open) >> Java HotSpot(TM) 64-Bit Server VM (build 16-internal+0-adhoc.iklam.open, mixed mode, sharing) >> >> $ java -Xlog:gc=error::foo -version >> [0.000s][error][logging] Invalid decorator 'foo'. >> Invalid -Xlog option '-Xlog:gc=error::foo', see error log for details. >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. > > In this PR I chose a warning level to ignore the invalid option and run a application. It isn't serious thing and some people might run with invalid option already. > > The fourth option is for output-option and can be described relatively free. So I suspect that it is ignored even when it is invalid. I think a warning is okay in this context. ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From iklam at openjdk.java.net Thu Dec 10 01:53:35 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 01:53:35 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options [v2] In-Reply-To: References: Message-ID: <6UHc2SXV085OmFM-1ez_s1cypUf72ge8JcK91xDBbMQ=.c7c9dd82-20c9-4d8d-92a2-fe3f85062942@github.com> On Tue, 8 Dec 2020 23:59:54 GMT, Koichi Sakata wrote: >> In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). >> But it?s possible to specify options with more colons like `java -Xlog:::::`. >> It?s better to show a message when more options are specified than maximum number. >> >> By this PR a warning message is outputted when options are specified more than the max number. > > Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: > > Change the warning message Agree that warning is OK. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1685 From ysuenaga at openjdk.java.net Thu Dec 10 04:08:35 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 10 Dec 2020 04:08:35 GMT Subject: RFR: 8257872: UL: -Xlog does not check number of options [v2] In-Reply-To: References: Message-ID: <5NkX5h9886qxpY8n2wcdaQIGxrCIPV1CxDEfcIwvCWo=.8461223b-cae6-40e5-9c77-bfe157296577@github.com> On Tue, 8 Dec 2020 23:59:54 GMT, Koichi Sakata wrote: >> In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). >> But it?s possible to specify options with more colons like `java -Xlog:::::`. >> It?s better to show a message when more options are specified than maximum number. >> >> By this PR a warning message is outputted when options are specified more than the max number. > > Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: > > Change the warning message Looks good! I will sponsor you. ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1685 From ksakata at openjdk.java.net Thu Dec 10 04:08:36 2020 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 10 Dec 2020 04:08:36 GMT Subject: Integrated: 8257872: UL: -Xlog does not check number of options In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 03:02:03 GMT, Koichi Sakata wrote: > In Unified Logging options can be specified up to four (`-Xlog[:[selections][:[output][:[decorators][:output-options]]]]`). > But it?s possible to specify options with more colons like `java -Xlog:::::`. > It?s better to show a message when more options are specified than maximum number. > > By this PR a warning message is outputted when options are specified more than the max number. This pull request has now been integrated. Changeset: 34650f52 Author: Koichi Sakata Committer: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/34650f52 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8257872: UL: -Xlog does not check number of options Reviewed-by: dholmes, iklam, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/1685 From dholmes at openjdk.java.net Thu Dec 10 07:10:35 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Dec 2020 07:10:35 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. Hi Gerard, Functionally this is fine. Stylistically I would have just done simply: return (act.sa_flags & SA_SIGINFO) != 0 ? CAST_FROM_FN_PTR(address, act.sa_sigaction) : CAST_FROM_FN_PTR(address, act.sa_handler); Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1680 From dholmes at openjdk.java.net Thu Dec 10 07:52:33 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Dec 2020 07:52:33 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 13:35:24 GMT, Thomas Stuefe wrote: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas Hi Thomas, This looks good - I like the common handling (though I dislike the need for the zero case :( ). Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From tschatzl at openjdk.java.net Thu Dec 10 10:34:49 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 10 Dec 2020 10:34:49 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. > > There some points I would like to bring up in advance in this change that may be contentious: > - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. > - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review2, comment updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1661/files - new: https://git.openjdk.java.net/jdk/pull/1661/files/213fbeed..5805fabe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1661&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1661&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1661/head:pull/1661 PR: https://git.openjdk.java.net/jdk/pull/1661 From tschatzl at openjdk.java.net Thu Dec 10 10:50:37 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 10 Dec 2020 10:50:37 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v2] In-Reply-To: References: Message-ID: <6KzerbJs7UifQj02OfcYgJVcvwl6ttyOo_WerZWykso=.b4b3c86f-6548-47d2-9a06-4fd8a3e44cbb@github.com> On Wed, 9 Dec 2020 23:02:54 GMT, Ioi Lam wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > Marked as reviewed by iklam (Reviewer). I fixed the mentioned comments but would like to defer further cleanup of the classes, particularly those `VM_GC_Operation`s that do not actually participate in the skipping protocol to [JDK-8258029](https://bugs.openjdk.java.net/browse/JDK-8258029) I filed just now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From kbarrett at openjdk.java.net Thu Dec 10 11:44:35 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 11:44:35 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v3] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 10:34:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. >> - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review2, comment updates Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From hseigel at openjdk.java.net Thu Dec 10 13:44:35 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 13:44:35 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Mandy, Could you regression test this change against the JCK lang and vm test suites and Mach5 tiers 1 and 2? Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From hseigel at openjdk.java.net Thu Dec 10 14:03:32 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 14:03:32 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Hi Mandy, Could you replace the comment starting at line 1854 in jvm.cpp with: // A class is a record if and only if it is final and a direct subclass // of java.lang.Record and the presence of `Record` attribute; // otherwise, it is not a record. Also, replace the comment starting at line 1872 in jvm.cpp with: // Returns an array containing the components of the Record attribute, // or NULL if the attribute is not present. // // Note that this function returns the components of the Record // attribute even if the class is not a Record. Also, please change the name of the attribute in the comments added to Class.java from RecordComponent to Record. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From chegar at openjdk.java.net Thu Dec 10 14:16:34 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 10 Dec 2020 14:16:34 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From forax at univ-mlv.fr Thu Dec 10 14:26:12 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Dec 2020 15:26:12 +0100 (CET) Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: <1230567086.503526.1607610372813.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mandy Chung" > ?: "core-libs-dev" , "hotspot-runtime-dev" > Envoy?: Mercredi 9 D?cembre 2020 01:43:34 > Objet: Re: RFR: 8257596: Clarify trusted final fields for record classes > On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on >> classes with Record attributes. That introduces a regression in >> `InstanceKlass::is_record` that returns true on a non-record class which has >> `RecordComponents` attribute present. This causes unexpected semantics in >> `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust >> final fields for non-record classes. >> >> I propose to change `InstanceKlass::is_record` to match the JLS semantic of a >> record class, i.e. final direct subclass of `java.lang.Record` with the >> presence of `RecordComponents` attribute. There is no change to JVM class file >> validation. Also I propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and >> direct subclass of `java.lang.Record` with `RecordComponents` attribute >> - `JVM_GetRecordComponents` returns an `RecordComponents` array if >> `RecordComponents` attribute is present; otherwise, returns NULL. This does >> not check if it's a record class or not. So it may return non-null on a >> non-record class if it has `RecordComponents` attribute. So >> `JVM_GetRecordComponents` returns the content of the classfile. > > Hi Remi, > >> It's not an issue, the JVM view of what a record is and the JLS view of what a >> record is doesn't have to be identical, >> only aligned. It's fine for the VM to consider any class that have a record >> Attribute is a record. >> >> We already had this discussion on amber-spec-expert list, >> see >> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html > > What is the conclusion (sorry it was unclear to me)? Drop TNSFF for records? > > This issue is to fix the regression introduced by JDK-8255342. I expect > someone else will file a new JBS issue and implement what amber-spec-experts > decided. > >> We already know that the JLS definition of a record will have to be changed for >> inline record (an inline record is not direct subclass of j.l.Record because >> you have the reference projection in the middle). > > Yes I saw that. I updated > [JDK-8251041](https://bugs.openjdk.java.net/browse/JDK-8251041) to follow up. > >> The real issue is that the JIT optimisation and Field.set() should be aligned, >> VarHandle deosn't let you change a final field and Unsafe is unsafe, so the >> current problem is that Field.set() relies on the reflection api by calling >> Class.isRecord() which is not good because Classs.isRecord() returns the JLS >> view of the world not the JVM view of the world. >> >> As said in the mail chain above, for the JIT optimization, instead of listing >> all the new constructs, record, inline, etc, i propose to check the other way, >> only allow to set a final field is only allowed for plain old java class, so >> the VM should not have a method InstanceKlass::is_record but a method that >> return if a class is a plain class or not and this method should be called by >> the JIT and by Field.set (through a JVM entry point) >> so the fact the optimization will be done or not is not related to what the JLS >> think a record is, those are separated concern. > > I agree the current situation is not ideal which requires to declare all the new > constructs explicitly for TNSFF. However, it's a reasonable tradeoff to get > the JIT optimization for records in time while waiting for true TNSFF > investigation like JMM and other relevant specs. I see this just a stop-gap > solution. When the long-term TNSFF is in place, the spec can be updated to > drop the explicit list of record, inline, etc. > > A related issue is > [JDK-8233873](https://bugs.openjdk.java.net/browse/JDK-8233873). I'm happy if > we can do TNSFF in a different solution. > > Again this PR intends to fix the regression. Two options: > 1. Keep [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) and > implement as this proposed patch > 2. Backout [JDK-8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) > > I expect Chris and/or others will follow up the decision made by the > amber-spec-experts w.r.t. trusting finals in records. I'm okay with either > option. For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. R?mi > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1706 From iignatyev at openjdk.java.net Thu Dec 10 17:56:04 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Dec 2020 17:56:04 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 Message-ID: Hi all, could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` -- Igor ------------- Commit messages: - 8258054: runtime/sealedClasses/GetPermittedSubclasses.jcod must use 61 class file version Changes: https://git.openjdk.java.net/jdk/pull/1738/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1738&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258054 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1738.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1738/head:pull/1738 PR: https://git.openjdk.java.net/jdk/pull/1738 From mikael at openjdk.java.net Thu Dec 10 17:56:04 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 10 Dec 2020 17:56:04 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:49:38 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). > > testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` > > -- Igor I'm assuming there's no (good) way to pass in that version as a variable instead of hardcoding it? ------------- Marked as reviewed by mikael (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1738 From hseigel at openjdk.java.net Thu Dec 10 18:03:54 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 18:03:54 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:49:38 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). > > testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` > > -- Igor lgtm ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1738 From darcy at openjdk.java.net Thu Dec 10 18:08:58 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Dec 2020 18:08:58 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:49:38 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). > > testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` > > -- Igor Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1738 From iignatyev at openjdk.java.net Thu Dec 10 18:18:58 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Dec 2020 18:18:58 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:05:48 GMT, Joe Darcy wrote: >> Hi all, >> >> could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). >> >> testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` >> >> -- Igor > > Marked as reviewed by darcy (Reviewer). thanks for all the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1738 From iignatyev at openjdk.java.net Thu Dec 10 18:18:58 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Dec 2020 18:18:58 GMT Subject: Integrated: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:49:38 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch which updates class file version in `test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclasses.jcod`? [8257450](https://bugs.openjdk.java.net/browse/JDK-8257450] has updated only one class defined by `GetPermittedSubclasses.jcod`, this patch updates the 2nd (out of 2). > > testing: `runtime/sealedClasses/GetPermittedSubclassesTest.java` > > -- Igor This pull request has now been integrated. Changeset: 3342ecaf Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/3342ecaf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 Reviewed-by: mikael, hseigel, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/1738 From redestad at openjdk.java.net Thu Dec 10 19:59:05 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Dec 2020 19:59:05 GMT Subject: RFR: 8258059: Clean up MethodData::profile_unsafe Message-ID: Following up on comments to #1733 - Simplify by using Symbol::starts_with - Bytecode_invoke methods are not inlineable, so locals avoid redundant calls ------------- Commit messages: - 8258059: Clean up MethodData::profile_unsafe Changes: https://git.openjdk.java.net/jdk/pull/1740/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1740&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258059 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1740.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1740/head:pull/1740 PR: https://git.openjdk.java.net/jdk/pull/1740 From gziemski at openjdk.java.net Thu Dec 10 20:08:00 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Dec 2020 20:08:00 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Thu, 10 Dec 2020 07:08:13 GMT, David Holmes wrote: > Hi Gerard, > Functionally this is fine. Stylistically I would have just done simply: > > return (act.sa_flags & SA_SIGINFO) != 0 ? CAST_FROM_FN_PTR(address, act.sa_sigaction) : CAST_FROM_FN_PTR(address, act.sa_handler); > > Thanks, > David Thank you David for the review, but I need to pull it out of JDK16 and redo for JDK17. I think I need to withdraw and close it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From gziemski at openjdk.java.net Thu Dec 10 20:08:02 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Dec 2020 20:08:02 GMT Subject: Withdrawn: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From gziemski at openjdk.java.net Thu Dec 10 20:16:57 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Dec 2020 20:16:57 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Thu, 10 Dec 2020 20:03:47 GMT, Gerard Ziemski wrote: >> Hi Gerard, >> Functionally this is fine. Stylistically I would have just done simply: >> >> return (act.sa_flags & SA_SIGINFO) != 0 ? CAST_FROM_FN_PTR(address, act.sa_sigaction) : CAST_FROM_FN_PTR(address, act.sa_handler); >> >> Thanks, >> David > >> Hi Gerard, >> Functionally this is fine. Stylistically I would have just done simply: >> >> return (act.sa_flags & SA_SIGINFO) != 0 ? CAST_FROM_FN_PTR(address, act.sa_sigaction) : CAST_FROM_FN_PTR(address, act.sa_handler); >> >> Thanks, >> David > > Thank you David for the review, but I need to pull it out of JDK16 and redo for JDK17. I think I need to withdraw and close it. I was told that all I need to do is to wait till official JDK16->JDK17 switch over, and can use this PR for JDK17. ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From darcy at openjdk.java.net Thu Dec 10 21:06:56 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Dec 2020 21:06:56 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:52:27 GMT, Mikael Vidstedt wrote: > > > I'm assuming there's no (good) way to pass in that version as a variable instead of hardcoding it? To my knowledge, such a mechanism does not currently exist. Perhaps we should build one :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1738 From hseigel at openjdk.java.net Thu Dec 10 21:20:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 10 Dec 2020 21:20:57 GMT Subject: RFR: 8258054: runtime/sealedClasses/GetPermittedSubclassesTest.java fails w/ jdk17 In-Reply-To: References: Message-ID: <60mzYlHL2FabwRcKahHd1oL5sk9QvCJJ4G7rrzesevA=.c97ff8de-5f69-4564-b24d-fec9aa78c947@github.com> On Thu, 10 Dec 2020 21:04:01 GMT, Joe Darcy wrote: >> I'm assuming there's no (good) way to pass in that version as a variable instead of hardcoding it? > >> >> >> I'm assuming there's no (good) way to pass in that version as a variable instead of hardcoding it? > > To my knowledge, such a mechanism does not currently exist. Perhaps we should build one :-) I don't know of such a mechanism.? For preview feature tests containing jasm and jcod files, we would only need a mechanism that would put in the latest supported major version when they are being compiled. Harold On 12/10/2020 4:04 PM, Joe Darcy wrote: > > I'm assuming there's no (good) way to pass in that version as a > variable instead of hardcoding it? > > To my knowledge, such a mechanism does not currently exist. Perhaps we > should build one :-) > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/1738 From iignatyev at openjdk.java.net Thu Dec 10 22:25:01 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Dec 2020 22:25:01 GMT Subject: [jdk16] RFR: 8258065: ProblemList JfrGTestAdaptiveSampling In-Reply-To: <53sM5TTrkRhD799gfNtVjJ_VMPt9Qrd7pm_2-ABgpR8=.31bd7ecf-0bac-4820-891a-72a29c598bca@github.com> References: <53sM5TTrkRhD799gfNtVjJ_VMPt9Qrd7pm_2-ABgpR8=.31bd7ecf-0bac-4820-891a-72a29c598bca@github.com> Message-ID: On Thu, 10 Dec 2020 22:13:54 GMT, Markus Gr?nlund wrote: > ProblemList / disable gtest JfrGTestAdaptiveSampling. > > Thanks > Markus LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/3 From mgronlun at openjdk.java.net Thu Dec 10 22:27:57 2020 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 10 Dec 2020 22:27:57 GMT Subject: [jdk16] Integrated: 8258065: ProblemList JfrGTestAdaptiveSampling In-Reply-To: <53sM5TTrkRhD799gfNtVjJ_VMPt9Qrd7pm_2-ABgpR8=.31bd7ecf-0bac-4820-891a-72a29c598bca@github.com> References: <53sM5TTrkRhD799gfNtVjJ_VMPt9Qrd7pm_2-ABgpR8=.31bd7ecf-0bac-4820-891a-72a29c598bca@github.com> Message-ID: On Thu, 10 Dec 2020 22:13:54 GMT, Markus Gr?nlund wrote: > ProblemList / disable gtest JfrGTestAdaptiveSampling. > > Thanks > Markus This pull request has now been integrated. Changeset: e90d0d1d Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk16/commit/e90d0d1d Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8258065: ProblemList JfrGTestAdaptiveSampling Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk16/pull/3 From mchung at openjdk.java.net Thu Dec 10 22:58:55 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Dec 2020 22:58:55 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 14:13:27 GMT, Chris Hegarty wrote: >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. >> >> I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: >> - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute >> - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. > > Marked as reviewed by chegar (Reviewer). Hi Remi, > For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. > And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk > And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From mchung at openjdk.java.net Thu Dec 10 23:01:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Dec 2020 23:01:57 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> On Thu, 10 Dec 2020 22:56:34 GMT, Mandy Chung wrote: >> Marked as reviewed by chegar (Reviewer). > > Hi Remi, > >> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. >> And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. > > This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk > >> And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. > > It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. I have created a new branch off jdk16: https://github.com/mlchung/jdk16/tree/8257596. It fixed the attribute name as Harold pointed out. @hseigel tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From jiefu at openjdk.java.net Fri Dec 11 03:18:54 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 11 Dec 2020 03:18:54 GMT Subject: RFR: 8258073: x86_32 build broken after JDK-8257731 In-Reply-To: References: Message-ID: <0aNW69iOubbOa5Q6t52Yb0qwnqHGz_bPQAk1k3-6E7Y=.f6b434ba-3e5a-4293-b431-b36b44d69037@github.com> On Fri, 11 Dec 2020 02:49:20 GMT, Jie Fu wrote: > Hi all, > > Please review the one-line change for x86_32 build fix. > > Thanks. > Best regards, > Jie Should be forwarded to hotspot-runtime ------------- PR: https://git.openjdk.java.net/jdk/pull/1743 From iklam at openjdk.java.net Fri Dec 11 03:40:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 03:40:54 GMT Subject: RFR: 8258073: x86_32 build broken after JDK-8257731 In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 02:49:20 GMT, Jie Fu wrote: > Hi all, > > Please review the one-line change for x86_32 build fix. > > Thanks. > Best regards, > Jie Looks good and trivial to me. Sorry for the breakage. I've added linux-x86 into my test matrix for similar changes in the future. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1743 From jiefu at openjdk.java.net Fri Dec 11 03:40:55 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 11 Dec 2020 03:40:55 GMT Subject: RFR: 8258073: x86_32 build broken after JDK-8257731 In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 03:33:45 GMT, Ioi Lam wrote: >> Hi all, >> >> Please review the one-line change for x86_32 build fix. >> >> Thanks. >> Best regards, >> Jie > > Looks good and trivial to me. Sorry for the breakage. I've added linux-x86 into my test matrix for similar changes in the future. Thanks @iklam for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1743 From jiefu at openjdk.java.net Fri Dec 11 03:40:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 11 Dec 2020 03:40:56 GMT Subject: Integrated: 8258073: x86_32 build broken after JDK-8257731 In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 02:49:20 GMT, Jie Fu wrote: > Hi all, > > Please review the one-line change for x86_32 build fix. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 8befc321 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/8befc321 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8258073: x86_32 build broken after JDK-8257731 Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1743 From stuefe at openjdk.java.net Fri Dec 11 07:22:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 07:22:04 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. Hi Gerard, I was confused about the patch. Its fine from a simplification standpoint - putting all those ? expressions into one place - but where were we relying on different storage? Cheers, Thomas src/hotspot/os/posix/signals_posix.cpp line 743: > 741: // Implementation may use the same storage for both the sa_sigaction field and the sa_handler field, > 742: // so check for "sigAct.sa_flags == SA_SIGINFO" > 743: static address get_signal_handler(struct sigaction action) { This copies the structure by value. While the compiler will probably optimize this out, I'd still not do it. Please use static address get_signal_handler(const struct sigaction*) instead. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1680 From david.holmes at oracle.com Fri Dec 11 07:28:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2020 17:28:41 +1000 Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: Hi Thomas, On 11/12/2020 5:22 pm, Thomas Stuefe wrote: > On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > >> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > Hi Gerard, > > I was confused about the patch. Its fine from a simplification standpoint - putting all those ? expressions into one place - but where were we relying on different storage? We were reading both fields from the same structure without checking the flag value: void* oldhand = oldAct.sa_sigaction ? CAST_FROM_FN_PTR(void*, oldAct.sa_sigaction) : CAST_FROM_FN_PTR(void*, oldAct.sa_handler); Cheers, David > Cheers, Thomas > > src/hotspot/os/posix/signals_posix.cpp line 743: > >> 741: // Implementation may use the same storage for both the sa_sigaction field and the sa_handler field, >> 742: // so check for "sigAct.sa_flags == SA_SIGINFO" >> 743: static address get_signal_handler(struct sigaction action) { > > This copies the structure by value. While the compiler will probably optimize this out, I'd still not do it. Please use > static address get_signal_handler(const struct sigaction*) > > instead. > > ------------- > > Changes requested by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1680 > From stuefe at openjdk.java.net Fri Dec 11 08:37:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 08:37:54 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Fri, 11 Dec 2020 06:29:06 GMT, Thomas Stuefe wrote: >> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > Hi Gerard, > > I was confused about the patch. Its fine from a simplification standpoint - putting all those ? expressions into one place - but where were we relying on different storage? > > Cheers, Thomas > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > Hi Thomas, > > On 11/12/2020 5:22 pm, Thomas Stuefe wrote: > > > On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > > > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > > > > > Hi Gerard, > > I was confused about the patch. Its fine from a simplification standpoint - putting all those ? expressions into one place - but where were we relying on different storage? > > We were reading both fields from the same structure without checking the > flag value: > > void* oldhand = oldAct.sa_sigaction > ? CAST_FROM_FN_PTR(void*, oldAct.sa_sigaction) > : CAST_FROM_FN_PTR(void*, oldAct.sa_handler); > > Cheers, > David Ah, I missed that. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From roland at openjdk.java.net Fri Dec 11 09:17:59 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Fri, 11 Dec 2020 09:17:59 GMT Subject: RFR: 8258059: Clean up MethodData::profile_unsafe In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:30:34 GMT, Claes Redestad wrote: > Following up on comments to #1733 > > - Simplify by using Symbol::starts_with > - Bytecode_invoke methods are not inlineable, so locals avoid redundant calls Marked as reviewed by roland (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1740 From chegar at openjdk.java.net Fri Dec 11 09:36:54 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Dec 2020 09:36:54 GMT Subject: RFR: 8258059: Clean up MethodData::profile_unsafe In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:30:34 GMT, Claes Redestad wrote: > Following up on comments to #1733 > > - Simplify by using Symbol::starts_with > - Bytecode_invoke methods are not inlineable, so locals avoid redundant calls Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1740 From redestad at openjdk.java.net Fri Dec 11 09:57:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 09:57:55 GMT Subject: RFR: 8258059: Clean up MethodData::profile_unsafe In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 09:15:37 GMT, Roland Westrelin wrote: >> Following up on comments to #1733 >> >> - Simplify by using Symbol::starts_with >> - Bytecode_invoke methods are not inlineable, so locals avoid redundant calls > > Marked as reviewed by roland (Reviewer). @rwestrel @ChrisHegarty - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1740 From tschatzl at openjdk.java.net Fri Dec 11 10:01:59 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 10:01:59 GMT Subject: Withdrawn: 8256641: CDS VM operations do not lock the heap In-Reply-To: References: Message-ID: <1XWPwVQosrcoUFibuMd0N2tm6zm61sDenqPZ-o0Iymc=.a3cad6ef-09a1-47dd-8a3e-3e2786c2c46a@github.com> On Mon, 7 Dec 2020 11:23:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > `VM_PopulateDumpSharedSpace`, `VM_PopulateDynamicDumpSharedSpace` and `VM_Verify` are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the `Heap_lock`, so the suggested solution is based on having all these VM operations descend from a new `VM_GC_Sync_Operation` `VM_Operation` which does that (and only that), split out from `VM_GC_Operation`. > > There some points I would like to bring up in advance in this change that may be contentious: > - each VM Operation could handle `Heap_lock` by itself, which I considered to be too error-prone. > - the need for `VM_Verify` to coordinate with garbage collections is new and has been introduced with [JDK-8253081](https://bugs.openjdk.java.net/browse/JDK-8253081) as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses `VM_Verify`, that operation now gets the `Heap_lock` too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > - so this change adds a new VM Operation class called `VM_GC_Sync_Operation` that splits off the handling of `Heap_lock` (i.e. the actual synchronization` from `VM_GC_Operation`. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the `VM_Populate*` or even `VM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From tschatzl at openjdk.java.net Fri Dec 11 10:01:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 10:01:58 GMT Subject: RFR: 8256641: CDS VM operations do not lock the heap [v3] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 11:41:35 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review2, comment updates > > Marked as reviewed by kbarrett (Reviewer). This is a change originally meant for JDK16, but the fork has occurred before integration. So re-requesting a pull [there](https://github.com/openjdk/jdk16/pull/8) ------------- PR: https://git.openjdk.java.net/jdk/pull/1661 From kbarrett at openjdk.java.net Fri Dec 11 10:06:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Dec 2020 10:06:00 GMT Subject: [jdk16] RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> References: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> Message-ID: On Fri, 11 Dec 2020 09:57:14 GMT, Thomas Schatzl wrote: > (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) > > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. > > There some points I would like to bring up in advance in this change that may be contentious: > > each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. > the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) Still looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/8 From tschatzl at openjdk.java.net Fri Dec 11 10:06:00 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 10:06:00 GMT Subject: [jdk16] RFR: 8256641: CDS VM operations do not lock the heap Message-ID: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) Hi all, can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. There some points I would like to bring up in advance in this change that may be contentious: each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) ------------- Commit messages: - kbarrett review2, comment fixup - kbarrett review - Initial commit Changes: https://git.openjdk.java.net/jdk16/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256641 Stats: 100 lines in 10 files changed: 65 ins; 15 del; 20 mod Patch: https://git.openjdk.java.net/jdk16/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/8/head:pull/8 PR: https://git.openjdk.java.net/jdk16/pull/8 From tschatzl at openjdk.java.net Fri Dec 11 10:06:00 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 10:06:00 GMT Subject: [jdk16] RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> References: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> Message-ID: On Fri, 11 Dec 2020 09:57:14 GMT, Thomas Schatzl wrote: > (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) > > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. > > There some points I would like to bring up in advance in this change that may be contentious: > > each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. > the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) No changes from original, applies cleany. ------------- PR: https://git.openjdk.java.net/jdk16/pull/8 From redestad at openjdk.java.net Fri Dec 11 11:28:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 11:28:55 GMT Subject: Integrated: 8258059: Clean up MethodData::profile_unsafe In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:30:34 GMT, Claes Redestad wrote: > Following up on comments to #1733 > > - Simplify by using Symbol::starts_with > - Bytecode_invoke methods are not inlineable, so locals avoid redundant calls This pull request has now been integrated. Changeset: ff75ad51 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/ff75ad51 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8258059: Clean up MethodData::profile_unsafe Reviewed-by: roland, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/1740 From iklam at openjdk.java.net Fri Dec 11 16:16:59 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 16:16:59 GMT Subject: [jdk16] RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> References: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> Message-ID: On Fri, 11 Dec 2020 09:57:14 GMT, Thomas Schatzl wrote: > (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) > > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. > > There some points I would like to bring up in advance in this change that may be contentious: > > each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. > the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/8 From iklam at openjdk.java.net Fri Dec 11 17:26:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 17:26:06 GMT Subject: RFR: 8257229: gtest death tests fail with unrecognized stderr output Message-ID: The regexp used by the TEST_VM_ASSERT_MSG macro is too restrictive. It shouldn't require that "assert failed" to be the very beginning of the VM output. Note that the other macro, TEST_VM_ASSERT, does not have the "^" in its regexp. ------------- Commit messages: - 8257229: gtest death tests fail with unrecognized stderr output Changes: https://git.openjdk.java.net/jdk/pull/1748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257229 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1748/head:pull/1748 PR: https://git.openjdk.java.net/jdk/pull/1748 From mchung at openjdk.java.net Fri Dec 11 18:08:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 18:08:56 GMT Subject: RFR: 8257596: Clarify trusted final fields for record classes In-Reply-To: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> References: <9rP40aGY5L27zoeic4iqCENI_ri8j1JHry0Yan0x9hg=.d6bd721e-b716-4a49-821f-9b9fc99dac5b@github.com> Message-ID: On Thu, 10 Dec 2020 22:59:16 GMT, Mandy Chung wrote: >> Hi Remi, >> >>> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record. >>> And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not. >> >> This reply was before you realized that records are are permanent Java SE 16 feature :-) If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk >> >>> And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation. >> >> It's the implementation details of the core reflection how to determine if a class is a member of another class. The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class. This indeed needs some investigation what the best way to address this. > > I have created a new branch off jdk16: https://github.com/mlchung/jdk16/tree/8257596. It fixed the attribute name as Harold pointed out. > > @hseigel tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed. Target this fix for jdk16 (https://github.com/openjdk/jdk16/pull/14). ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From mchung at openjdk.java.net Fri Dec 11 18:08:57 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Dec 2020 18:08:57 GMT Subject: Withdrawn: 8257596: Clarify trusted final fields for record classes In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on classes with `RecordComponents` attributes. That introduces a regression in `InstanceKlass::is_record` that returns true on a non-record class which has `RecordComponents` attribute present. This causes unexpected semantics in `JVM_IsRecord` and `JVM_GetRecordComponents` and also a regression to trust final fields for non-record classes. > > I propose to change `InstanceKlass::is_record` to match the JLS semantic of a record class, i.e. final direct subclass of `java.lang.Record` with the presence of `RecordComponents` attribute. There is no change to JVM class file validation. Also I propose clearly define: > - `JVM_IsRecord` returns true if the given class is a record i.e. final and direct subclass of `java.lang.Record` with `RecordComponents` attribute > - `JVM_GetRecordComponents` returns an `RecordComponents` array if `RecordComponents` attribute is present; otherwise, returns NULL. This does not check if it's a record class or not. So it may return non-null on a non-record class if it has `RecordComponents` attribute. So `JVM_GetRecordComponents` returns the content of the classfile. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1706 From tschatzl at openjdk.java.net Fri Dec 11 18:17:56 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 18:17:56 GMT Subject: [jdk16] RFR: 8256641: CDS VM operations do not lock the heap In-Reply-To: References: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> Message-ID: On Fri, 11 Dec 2020 10:02:27 GMT, Kim Barrett wrote: >> (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) >> >> Hi all, >> >> can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? >> >> VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. >> >> (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) >> >> They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. >> >> The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. >> >> There some points I would like to bring up in advance in this change that may be contentious: >> >> each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. >> the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. >> One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. >> so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. >> >> Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) > > Still looks good. Thanks @kimbarrett @iklam for your reviews. ------------- PR: https://git.openjdk.java.net/jdk16/pull/8 From tschatzl at openjdk.java.net Fri Dec 11 18:17:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 18:17:58 GMT Subject: [jdk16] Integrated: 8256641: CDS VM operations do not lock the heap In-Reply-To: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> References: <-0YZek3j3ujXtj6cBFiodRLUqpdVySISpUGHYfN0Wu8=.fff6c370-b895-4e0c-a1a1-83070b0c9577@github.com> Message-ID: On Fri, 11 Dec 2020 09:57:14 GMT, Thomas Schatzl wrote: > (Originally started in openjdk/jdk [PR #1161](https://github.com/openjdk/jdk/pull/1661), but the fork happened before pushing) > > Hi all, > > can I get reviews for this change that adds missing synchronization of CDS related VM operations with other heap operations? > > VM_PopulateDumpSharedSpace, VM_PopulateDynamicDumpSharedSpace and VM_Verify are used during CDS operation, one for creating the CDS archive (eventually doing a GC), one for mapping in the CDS archive into the heap, and the last one for verification. > > (Fwiw, imho the first two are awfully close and should be renamed to be better distinguishable, but that's another matter) > > They all in one way or the other need to synchronize with garbage collection as they may either do a GC or just do verification, as actual (STW-)gc returns an uninitialized block of memory that is not parseable; and before that block of memory can be initialized, another VM operation like one of the mentioned could be started otherwise seeing that uninitialized memory and crashing. > > The existing mechanism to prevent this kind of interference is taking the Heap_lock, so the suggested solution is based on having all these VM operations descend from a new VM_GC_Sync_Operation VM_Operation which does that (and only that), split out from VM_GC_Operation. > > There some points I would like to bring up in advance in this change that may be contentious: > > each VM Operation could handle Heap_lock by itself, which I considered to be too error-prone. > the need for VM_Verify to coordinate with garbage collections is new and has been introduced with JDK-8253081 as since then a Java thread might execute it - that's why this hasn't been a problem before. That could be undone (removed), but I kind of believe that with more expected changes to the CDS mechanism in the future the additional full-heap verification after loading the archive is worth the additional effort. > One (implementation) drawback is that since ZGC also uses VM_Verify, that operation now gets the Heap_lock too, and is kind of also using some part of the "set of operations related to GC" in general but did not so before, keeping almost completely separate. Testing did not show an issue, and I tried to look at the code carefully to see whether there could be issues with no result. (I.e. I couldn't find an issue). Obviously I'd like to ask you to look over this again. > so this change adds a new VM Operation class called VM_GC_Sync_Operation that splits off the handling of Heap_lock (i.e. the actual synchronizationfromVM_GC_Operation. The reason is that I do not think the logic for the gc VM operation that prevents multiple back-to-back GC operations is a good fit for any of the VM_Populate*or evenVM_Verify` operations. > > Testing: tier1-5; test case attached to the CR; other known reproducers (runtime/valhalla/inlinetypes/InlineOops.java in the Valhalla repo) This pull request has now been integrated. Changeset: bacf22b9 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk16/commit/bacf22b9 Stats: 100 lines in 10 files changed: 65 ins; 15 del; 20 mod 8256641: CDS VM operations do not lock the heap Reviewed-by: kbarrett, iklam ------------- PR: https://git.openjdk.java.net/jdk16/pull/8 From gziemski at openjdk.java.net Fri Dec 11 19:35:56 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 11 Dec 2020 19:35:56 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Fri, 11 Dec 2020 06:26:21 GMT, Thomas Stuefe wrote: >> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > src/hotspot/os/posix/signals_posix.cpp line 743: > >> 741: // Implementation may use the same storage for both the sa_sigaction field and the sa_handler field, >> 742: // so check for "sigAct.sa_flags == SA_SIGINFO" >> 743: static address get_signal_handler(struct sigaction action) { > > This copies the structure by value. While the compiler will probably optimize this out, I'd still not do it. Please use > static address get_signal_handler(const struct sigaction*) > > instead. Thank you Thomas for the review. How about: `static address get_signal_handler(struct sigaction &action)` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From coleenp at openjdk.java.net Fri Dec 11 20:28:54 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 20:28:54 GMT Subject: RFR: 8257229: gtest death tests fail with unrecognized stderr output In-Reply-To: References: Message-ID: <8YqsJPuXzxjdXPb4kDZ3cSBsTQm6xFEDXmYhvwZ4My0=.f49714e5-f70a-4d60-bc30-b8f8e0b7e86b@github.com> On Fri, 11 Dec 2020 17:18:08 GMT, Ioi Lam wrote: > The regexp used by the TEST_VM_ASSERT_MSG macro is too restrictive. It shouldn't require that "assert failed" to be the very beginning of the VM output. Note that the other macro, TEST_VM_ASSERT, does not have the "^" in its regexp. Ok. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1748 From minqi at openjdk.java.net Fri Dec 11 20:32:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 11 Dec 2020 20:32:55 GMT Subject: RFR: 8257229: gtest death tests fail with unrecognized stderr output In-Reply-To: References: Message-ID: <1PtttFXtkAjPWnd5sXRsfuZF3xyoCmeD225ZdisHspw=.0e05107d-1d38-4c59-9b41-7b5ba603ab0c@github.com> On Fri, 11 Dec 2020 17:18:08 GMT, Ioi Lam wrote: > The regexp used by the TEST_VM_ASSERT_MSG macro is too restrictive. It shouldn't require that "assert failed" to be the very beginning of the VM output. Note that the other macro, TEST_VM_ASSERT, does not have the "^" in its regexp. Looks good and trivial. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1748 From stuefe at openjdk.java.net Sat Dec 12 07:17:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Dec 2020 07:17:14 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Make SafeFetch work on Windows + AIX fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1695/files - new: https://git.openjdk.java.net/jdk/pull/1695/files/a7a94321..eb0efc1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1695&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1695&range=00-01 Stats: 26 lines in 2 files changed: 7 ins; 9 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1695/head:pull/1695 PR: https://git.openjdk.java.net/jdk/pull/1695 From stuefe at openjdk.java.net Sat Dec 12 07:26:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Dec 2020 07:26:56 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: <-U31UUHfazwzLhxP1cd_XoDw7TpCSCUts2XDdH-uYt8=.8319f095-1bb7-4004-a64d-9ff5ebd40fa3@github.com> On Thu, 10 Dec 2020 07:49:55 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Make SafeFetch work on Windows + AIX fix > > Hi Thomas, > This looks good - I like the common handling (though I dislike the need for the zero case :( ). > Thanks, > David Hi, I made this work on Windows too (thanks @kimbarrett for reminding me). This involved fixing `HandleException`, which is roughly the pendant of ucontext_set_pc() for Windows. I also combined dumplicate coding for the three Windows architectures. I excluded the `os_safefetch_negative` gtest for Windows, that won't work as long as we miss SEH for gtests, see https://bugs.openjdk.java.net/browse/JDK-8185734. This is not a big deal though since the `os_safefetch_negative_at_safepoint` gtest still works, which tests SafeFetch in the VMThread. I experimented with locally adding a SEH catcher around the SafeFetch call in the test, but I removed that coding because it introduced too much complexity for little gain. I also fixed a small issue for AIX where the zero page is readable so we need another guaranteed-to-be-invalid address. Since we need invalid addresses in a number of places in text code, I plan to centralize this definition at some point. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1695 From stuefe at openjdk.java.net Sat Dec 12 07:34:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Dec 2020 07:34:58 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Fri, 11 Dec 2020 19:33:07 GMT, Gerard Ziemski wrote: >> src/hotspot/os/posix/signals_posix.cpp line 743: >> >>> 741: // Implementation may use the same storage for both the sa_sigaction field and the sa_handler field, >>> 742: // so check for "sigAct.sa_flags == SA_SIGINFO" >>> 743: static address get_signal_handler(struct sigaction action) { >> >> This copies the structure by value. While the compiler will probably optimize this out, I'd still not do it. Please use >> static address get_signal_handler(const struct sigaction*) >> >> instead. > > Thank you Thomas for the review. > > How about: > > `static address get_signal_handler(struct sigaction &action)` > > ? Meh. I am not a big fan of references :) since at the call site they are indistinguishable from by-value parameters. But if you use them, please make them const. ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From kbarrett at openjdk.java.net Sat Dec 12 16:27:56 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 12 Dec 2020 16:27:56 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 07:17:14 GMT, Thomas Stuefe wrote: >> In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: >> >> JavaThread* thread = NULL; >> ... >> if(t->is_Java_thread()) { >> thread = (JavaThread*)t; >> } >> ... >> if (info != NULL && uc != NULL && thread != NULL) { >> pc = (address) os::Linux::ucontext_get_pc(uc); >> if (StubRoutines::is_safefetch_fault(pc)) { >> >> As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. >> >> This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. >> >> ---- >> >> The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. >> >> I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. >> >> To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. >> >> I added a gtest which reproduces the issue and used that to check that the patch works. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Make SafeFetch work on Windows + AIX fix New Windows changes look okay to me, but I'm not an expert in that area. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From stuefe at openjdk.java.net Sun Dec 13 15:56:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 13 Dec 2020 15:56:02 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution Message-ID: Hi, May I have reviews please for the following patch. At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. Whether or not our SEH handler gets involved currently depends on arbitrary factors: - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). This patch consists of two parts A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). ---- Notes: - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions ------------- Commit messages: - Make SEH work in gtests Changes: https://git.openjdk.java.net/jdk/pull/1757/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1757&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185734 Stats: 17 lines in 5 files changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1757.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1757/head:pull/1757 PR: https://git.openjdk.java.net/jdk/pull/1757 From dholmes at openjdk.java.net Mon Dec 14 04:48:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Dec 2020 04:48:57 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 07:17:14 GMT, Thomas Stuefe wrote: >> In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: >> >> JavaThread* thread = NULL; >> ... >> if(t->is_Java_thread()) { >> thread = (JavaThread*)t; >> } >> ... >> if (info != NULL && uc != NULL && thread != NULL) { >> pc = (address) os::Linux::ucontext_get_pc(uc); >> if (StubRoutines::is_safefetch_fault(pc)) { >> >> As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. >> >> This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. >> >> ---- >> >> The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. >> >> I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. >> >> To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. >> >> I added a gtest which reproduces the issue and used that to check that the patch works. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Make SafeFetch work on Windows + AIX fix One query, but changes can go in as-is. Thanks, David src/hotspot/os/windows/os_windows.cpp line 2258: > 2256: // Save pc in thread > 2257: if (thread != nullptr && thread->is_Java_thread()) { > 2258: thread->as_Java_thread()->set_saved_exception_pc((address)(DWORD_PTR)exceptionInfo->ContextRecord->PC_NAME); Is this a full fix? If the thread is not a JavaThread we no longer hit a problem in as_Java_thread() but is doing nothing for a non-JavaThread actually the right thing to do? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1695 From dholmes at openjdk.java.net Mon Dec 14 04:54:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Dec 2020 04:54:55 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews please for the following patch. > > At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. > > Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. > > Whether or not our SEH handler gets involved currently depends on arbitrary factors: > - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test > - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). > > This patch consists of two parts > > A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. > > B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. > > In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. > > The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. > > The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. > > Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). > > ---- > > Notes: > - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. > > - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html > [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions Hi Thomas, Not an expert but this all seems quite reasonable to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1757 From stuefe at openjdk.java.net Mon Dec 14 05:20:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 05:20:12 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v3] In-Reply-To: References: Message-ID: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Add missing include ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1695/files - new: https://git.openjdk.java.net/jdk/pull/1695/files/eb0efc1e..95e3a178 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1695&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1695&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1695/head:pull/1695 PR: https://git.openjdk.java.net/jdk/pull/1695 From stuefe at openjdk.java.net Mon Dec 14 05:24:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 05:24:57 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 04:44:43 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Make SafeFetch work on Windows + AIX fix > > src/hotspot/os/windows/os_windows.cpp line 2258: > >> 2256: // Save pc in thread >> 2257: if (thread != nullptr && thread->is_Java_thread()) { >> 2258: thread->as_Java_thread()->set_saved_exception_pc((address)(DWORD_PTR)exceptionInfo->ContextRecord->PC_NAME); > > Is this a full fix? If the thread is not a JavaThread we no longer hit a problem in as_Java_thread() but is doing nothing for a non-JavaThread actually the right thing to do? The saved_exception_pc mechanism is only implemented for JavaThreads. But all threads go through the code below, where we change the pc in the context structure. ------------- PR: https://git.openjdk.java.net/jdk/pull/1695 From stuefe at openjdk.java.net Mon Dec 14 05:54:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 05:54:55 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 04:52:02 GMT, David Holmes wrote: > Hi Thomas, > Not an expert but this all seems quite reasonable to me. > Thanks, > David Thanks David! ------------- PR: https://git.openjdk.java.net/jdk/pull/1757 From iklam at openjdk.java.net Mon Dec 14 07:03:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 14 Dec 2020 07:03:55 GMT Subject: RFR: 8257229: gtest death tests fail with unrecognized stderr output In-Reply-To: <8YqsJPuXzxjdXPb4kDZ3cSBsTQm6xFEDXmYhvwZ4My0=.f49714e5-f70a-4d60-bc30-b8f8e0b7e86b@github.com> References: <8YqsJPuXzxjdXPb4kDZ3cSBsTQm6xFEDXmYhvwZ4My0=.f49714e5-f70a-4d60-bc30-b8f8e0b7e86b@github.com> Message-ID: <7xif5Xr1kmLLBy7eCrxB86k6yAuxu3Bk3i3gmZt72Fc=.987ef148-f9f7-4f1c-955e-6e6d6978e728@github.com> On Fri, 11 Dec 2020 20:26:41 GMT, Coleen Phillimore wrote: >> The regexp used by the TEST_VM_ASSERT_MSG macro is too restrictive. It shouldn't require that "assert failed" to be the very beginning of the VM output. Note that the other macro, TEST_VM_ASSERT, does not have the "^" in its regexp. > > Ok. Thanks @coleenp & @yminqi for the review. Tested with mach5 tiers1/2. ------------- PR: https://git.openjdk.java.net/jdk/pull/1748 From iklam at openjdk.java.net Mon Dec 14 07:03:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 14 Dec 2020 07:03:56 GMT Subject: Integrated: 8257229: gtest death tests fail with unrecognized stderr output In-Reply-To: References: Message-ID: <-tFts3u0em79wliZpIvs_9x3xtGjin6YkR3P60Osvbs=.0e2593da-0ac7-4890-a05a-6bf0a780a58e@github.com> On Fri, 11 Dec 2020 17:18:08 GMT, Ioi Lam wrote: > The regexp used by the TEST_VM_ASSERT_MSG macro is too restrictive. It shouldn't require that "assert failed" to be the very beginning of the VM output. Note that the other macro, TEST_VM_ASSERT, does not have the "^" in its regexp. This pull request has now been integrated. Changeset: c30fff7c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c30fff7c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8257229: gtest death tests fail with unrecognized stderr output Reviewed-by: coleenp, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1748 From stuefe at openjdk.java.net Mon Dec 14 07:32:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 07:32:57 GMT Subject: RFR: 8257229: gtest death tests fail with unrecognized stderr output In-Reply-To: <7xif5Xr1kmLLBy7eCrxB86k6yAuxu3Bk3i3gmZt72Fc=.987ef148-f9f7-4f1c-955e-6e6d6978e728@github.com> References: <8YqsJPuXzxjdXPb4kDZ3cSBsTQm6xFEDXmYhvwZ4My0=.f49714e5-f70a-4d60-bc30-b8f8e0b7e86b@github.com> <7xif5Xr1kmLLBy7eCrxB86k6yAuxu3Bk3i3gmZt72Fc=.987ef148-f9f7-4f1c-955e-6e6d6978e728@github.com> Message-ID: <9-hVKeL5kakD1BChWEDPU1FspzvpxnK6RbbBB0hVnQ0=.43dc29ba-2007-40b8-9eb1-d2f3940437d4@github.com> On Mon, 14 Dec 2020 07:00:15 GMT, Ioi Lam wrote: >> Ok. > > Thanks @coleenp & @yminqi for the review. Tested with mach5 tiers1/2. Nice, thanks for fixing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/1748 From david.holmes at oracle.com Mon Dec 14 07:33:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2020 17:33:48 +1000 Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: <11be21b2-0a3f-c375-086e-7c5c0ae43069@oracle.com> On 14/12/2020 3:24 pm, Thomas Stuefe wrote: > On Mon, 14 Dec 2020 04:44:43 GMT, David Holmes wrote: > >>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Make SafeFetch work on Windows + AIX fix >> >> src/hotspot/os/windows/os_windows.cpp line 2258: >> >>> 2256: // Save pc in thread >>> 2257: if (thread != nullptr && thread->is_Java_thread()) { >>> 2258: thread->as_Java_thread()->set_saved_exception_pc((address)(DWORD_PTR)exceptionInfo->ContextRecord->PC_NAME); >> >> Is this a full fix? If the thread is not a JavaThread we no longer hit a problem in as_Java_thread() but is doing nothing for a non-JavaThread actually the right thing to do? > > The saved_exception_pc mechanism is only implemented for JavaThreads. But all threads go through the code below, where we change the pc in the context structure. My query is whether it makes sense for only JavaThreads to have this saved (C++?) exception pc? What role does it play and why would it not be applicable to all threads? (Sorry bit of a digression but trying to understand the bigger picture.) Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1695 > From stuefe at openjdk.java.net Mon Dec 14 08:34:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 08:34:55 GMT Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 04:46:25 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Make SafeFetch work on Windows + AIX fix > > One query, but changes can go in as-is. > Thanks, > David > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > On 14/12/2020 3:24 pm, Thomas Stuefe wrote: > > > On Mon, 14 Dec 2020 04:44:43 GMT, David Holmes wrote: > > > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > > > Make SafeFetch work on Windows + AIX fix > > > > > > > > > src/hotspot/os/windows/os_windows.cpp line 2258: > > > > 2256: // Save pc in thread > > > > 2257: if (thread != nullptr && thread->is_Java_thread()) { > > > > 2258: thread->as_Java_thread()->set_saved_exception_pc((address)(DWORD_PTR)exceptionInfo->ContextRecord->PC_NAME); > > > > > > > > > Is this a full fix? If the thread is not a JavaThread we no longer hit a problem in as_Java_thread() but is doing nothing for a non-JavaThread actually the right thing to do? > > > > > > The saved_exception_pc mechanism is only implemented for JavaThreads. But all threads go through the code below, where we change the pc in the context structure. > > My query is whether it makes sense for only JavaThreads to have this > saved (C++?) exception pc? What role does it play and why would it not > be applicable to all threads? (Sorry bit of a digression but trying to > understand the bigger picture.) > > Thanks, > David IIUC, JavaThread::_saved_exception_pc contains the pc from which a safepoint was triggered, and to which we may want to return once the safepoint was handled. Safepoint handling only works for java threads, so limiting this to JavaThread makes sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/1695 From dholmes at openjdk.java.net Mon Dec 14 23:16:06 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Dec 2020 23:16:06 GMT Subject: RFR: 8236225: Remove expired flags in JDK 17 Message-ID: 8236225: Remove expired flags in JDK 17 8256717: Expire the long term obsoleted VM flags The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. Updated any remaining references to the obsolete flags that are now expired. Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. Thanks, David ------------- Commit messages: - Add a dummy obsolete flag for testing purposes as we have no actual obsolete flags in JDK 17 at ths time. - Updated manpage - Update files (mainly tests) that referred to obsolete flags that are now expired. - Undo the change the CriticalJNINative - 8256717: Expire the long term obsoleted VM flags - 8236225: Remove expired flags in JDK 17 Changes: https://git.openjdk.java.net/jdk/pull/1773/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1773&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236225 Stats: 341 lines in 7 files changed: 118 ins; 213 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1773.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1773/head:pull/1773 PR: https://git.openjdk.java.net/jdk/pull/1773 From coleenp at openjdk.java.net Mon Dec 14 23:27:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 14 Dec 2020 23:27:02 GMT Subject: RFR: 8236225: Remove expired flags in JDK 17 In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 22:43:16 GMT, David Holmes wrote: > 8236225: Remove expired flags in JDK 17 > 8256717: Expire the long term obsoleted VM flags > > The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. > > Updated any remaining references to the obsolete flags that are now expired. > > Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. > > Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. > > Thanks, > David LGTM! src/hotspot/share/runtime/arguments.cpp line 540: > 538: // -------------- Obsolete Flags - sorted by expired_in -------------- > 539: > 540: #ifdef TEST_VERIFY_SPECIAL_JVM_FLAGS No objecting, but it doesn't look like we told them when it would become unrecognized. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1773 From kvn at openjdk.java.net Mon Dec 14 23:53:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 14 Dec 2020 23:53:57 GMT Subject: RFR: 8236225: Remove expired flags in JDK 17 In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 22:43:16 GMT, David Holmes wrote: > 8236225: Remove expired flags in JDK 17 > 8256717: Expire the long term obsoleted VM flags > > The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. > > Updated any remaining references to the obsolete flags that are now expired. > > Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. > > Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. > > Thanks, > David Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1773 From david.holmes at oracle.com Mon Dec 14 23:57:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 09:57:48 +1000 Subject: RFR: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads [v2] In-Reply-To: References: Message-ID: <3614b868-2c2b-2e13-83c2-a71c4693f69b@oracle.com> On 14/12/2020 6:34 pm, Thomas Stuefe wrote: > On Mon, 14 Dec 2020 04:46:25 GMT, David Holmes wrote: > >>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Make SafeFetch work on Windows + AIX fix >> >> One query, but changes can go in as-is. >> Thanks, >> David > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ >> >> On 14/12/2020 3:24 pm, Thomas Stuefe wrote: >> >>> On Mon, 14 Dec 2020 04:44:43 GMT, David Holmes wrote: >>>>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >>>>> Make SafeFetch work on Windows + AIX fix >>>> >>>> >>>> src/hotspot/os/windows/os_windows.cpp line 2258: >>>>> 2256: // Save pc in thread >>>>> 2257: if (thread != nullptr && thread->is_Java_thread()) { >>>>> 2258: thread->as_Java_thread()->set_saved_exception_pc((address)(DWORD_PTR)exceptionInfo->ContextRecord->PC_NAME); >>>> >>>> >>>> Is this a full fix? If the thread is not a JavaThread we no longer hit a problem in as_Java_thread() but is doing nothing for a non-JavaThread actually the right thing to do? >>> >>> >>> The saved_exception_pc mechanism is only implemented for JavaThreads. But all threads go through the code below, where we change the pc in the context structure. >> >> My query is whether it makes sense for only JavaThreads to have this >> saved (C++?) exception pc? What role does it play and why would it not >> be applicable to all threads? (Sorry bit of a digression but trying to >> understand the bigger picture.) >> >> Thanks, >> David > > IIUC, JavaThread::_saved_exception_pc contains the pc from which a safepoint was triggered, and to which we may want to return once the safepoint was handled. Safepoint handling only works for java threads, so limiting this to JavaThread makes sense. I see now that it relates to the safepoint polling page exception. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1695 > From dholmes at openjdk.java.net Tue Dec 15 00:03:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 15 Dec 2020 00:03:58 GMT Subject: RFR: 8236225: Remove expired flags in JDK 17 In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 23:23:46 GMT, Coleen Phillimore wrote: >> 8236225: Remove expired flags in JDK 17 >> 8256717: Expire the long term obsoleted VM flags >> >> The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. >> >> Updated any remaining references to the obsolete flags that are now expired. >> >> Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. >> >> Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. >> >> Thanks, >> David > > src/hotspot/share/runtime/arguments.cpp line 540: > >> 538: // -------------- Obsolete Flags - sorted by expired_in -------------- >> 539: >> 540: #ifdef TEST_VERIFY_SPECIAL_JVM_FLAGS > > No objecting, but it doesn't look like we told them when it would become unrecognized. We don't report that value in the warning we only report the release in which it became obsolete. e.g.: Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option PermSize; support was removed in 8.0 So to all intents and purposes you can read all these undefined() entries as if they said jdk(17). Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1773 From david.holmes at oracle.com Tue Dec 15 00:14:30 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 10:14:30 +1000 Subject: RFR: 8236225: Remove expired flags in JDK 17 In-Reply-To: References: Message-ID: <890e70fa-7277-1dcf-bead-7827cf6d7144@oracle.com> On 15/12/2020 9:53 am, Vladimir Kozlov wrote: > On Mon, 14 Dec 2020 22:43:16 GMT, David Holmes wrote: > >> 8236225: Remove expired flags in JDK 17 >> 8256717: Expire the long term obsoleted VM flags >> >> The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. >> >> Updated any remaining references to the obsolete flags that are now expired. >> >> Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. >> >> Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. >> >> Thanks, >> David > > Marked as reviewed by kvn (Reviewer). Thanks Vladimir! David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1773 > From stuefe at openjdk.java.net Tue Dec 15 07:03:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 07:03:58 GMT Subject: Integrated: JDK-8257828: SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 13:35:24 GMT, Thomas Stuefe wrote: > In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects: > > JavaThread* thread = NULL; > ... > if(t->is_Java_thread()) { > thread = (JavaThread*)t; > } > ... > if (info != NULL && uc != NULL && thread != NULL) { > pc = (address) os::Linux::ucontext_get_pc(uc); > if (StubRoutines::is_safefetch_fault(pc)) { > > As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM. > > This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads. > > ---- > > The patch makes handling of SafeFetch faults independent on whether the crashing thread is a JavaThread (indeed, whether we have a current Thread at all). This had been the case for AIX and Linux ppc, s390 before, since we already fixed this issue for our platform, so we know this works. > > I also hauled the SafeFetch handling out of the platform dependent part of the signal handler into the generic signal handler. This removes some duplicate coding. > > To be consistent, I moved the SafeFetch handling for Zero up into the generic signal handler too. Zero did not have a problem, but this reduces code. > > I added a gtest which reproduces the issue and used that to check that the patch works. > > Thanks, Thomas This pull request has now been integrated. Changeset: 3ab1dfeb Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Stats: 196 lines in 12 files changed: 102 ins; 83 del; 11 mod 8257828: SafeFetch may crash if invoked in non-JavaThreads Reviewed-by: mdoerr, kbarrett, coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1695 From ihse at openjdk.java.net Tue Dec 15 08:19:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 08:19:57 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews please for the following patch. > > At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. > > Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. > > Whether or not our SEH handler gets involved currently depends on arbitrary factors: > - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test > - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). > > This patch consists of two parts > > A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. > > B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. > > In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. > > The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. > > The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. > > Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). > > ---- > > Notes: > - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. > > - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html > [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions src/hotspot/os/windows/os_windows.cpp line 515: > 513: } > 514: > 515: JNIEXPORT I understand if you do not want to start a code cleanup, but it looks like this should be in an external .hpp file, which could then have been included by all the .cpp files, instead of having the declaration repeated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1757 From ihse at openjdk.java.net Tue Dec 15 08:23:55 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Dec 2020 08:23:55 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com> On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews please for the following patch. > > At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. > > Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. > > Whether or not our SEH handler gets involved currently depends on arbitrary factors: > - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test > - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). > > This patch consists of two parts > > A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. > > B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. > > In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. > > The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. > > The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. > > Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). > > ---- > > Notes: > - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. > > - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html > [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions Build changes look good. I left a note on the hotspot code; feel free to ignore it if you want. :) I agree with your assessment that restoring gtest to the code base would make life simpler. I'm not sure what needs to be done to do that; I suppose it needs someone to write and implement a JBS feature, and to publicly acknowledge that they intent to spend the time needed to keep it up to date with upstream going forward. (I also agree with your assessment on VEH replacing SEH, as my recollection of working with the runtime system on JRockit was that VEH was superior for the needs of a VM, and much closer to the posix signal model.) ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1757 From stuefe at openjdk.java.net Tue Dec 15 08:49:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 08:49:57 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 08:16:51 GMT, Magnus Ihse Bursie wrote: >> Hi, >> >> May I have reviews please for the following patch. >> >> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. >> >> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. >> >> Whether or not our SEH handler gets involved currently depends on arbitrary factors: >> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test >> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). >> >> This patch consists of two parts >> >> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. >> >> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. >> >> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. >> >> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. >> >> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. >> >> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). >> >> ---- >> >> Notes: >> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. >> >> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html >> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions > > src/hotspot/os/windows/os_windows.cpp line 515: > >> 513: } >> 514: >> 515: JNIEXPORT > > I understand if you do not want to start a code cleanup, but it looks like this should be in an external .hpp file, which could then have been included by all the .cpp files, instead of having the declaration repeated. I agree, but I would like to leave this out for now. I think at some point we may switch to Vectored Exception Handling for all Windows architectures, then we can remove this hideous coding in the gtest launcher main function again. And remove the export. ------------- PR: https://git.openjdk.java.net/jdk/pull/1757 From stuefe at openjdk.java.net Tue Dec 15 09:00:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 09:00:56 GMT Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com> References: <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com> Message-ID: <0Jkzd98oZ6ao67ytVmh96ivAEM6wmrCvnmrVFHfPtQI=.671a326a-46cd-4a04-9742-ae75c502d1b0@github.com> On Tue, 15 Dec 2020 08:20:54 GMT, Magnus Ihse Bursie wrote: > Build changes look good. > > I left a note on the hotspot code; feel free to ignore it if you want. :) > > I agree with your assessment that restoring gtest to the code base would make life simpler. I'm not sure what needs to be done to do that; I suppose it needs someone to write and implement a JBS feature, and to publicly acknowledge that they intent to spend the time needed to keep it up to date with upstream going forward. Yes, and unfortunately I cannot do this - I think this has to be driven from inside Oracle. > > (I also agree with your assessment on VEH replacing SEH, as my recollection of working with the runtime system on JRockit was that VEH was superior for the needs of a VM, and much closer to the posix signal model.) I also agree. @luhenry 's work convinced me, lets see when it bears fruit. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1757 From stuefe at openjdk.java.net Tue Dec 15 09:05:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 09:05:58 GMT Subject: Integrated: JDK-8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews please for the following patch. > > At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file. > > Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch. > > Whether or not our SEH handler gets involved currently depends on arbitrary factors: > - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test > - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH). > > This patch consists of two parts > > A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function. > > B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. > > In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream. > > The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. > > The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing. > > Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch). > > ---- > > Notes: > - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits. > > - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html > [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions This pull request has now been integrated. Changeset: 568dc29b Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/568dc29b Stats: 17 lines in 5 files changed: 17 ins; 0 del; 0 mod 8185734: [Windows] Structured Exception Catcher missing around gtest execution Reviewed-by: dholmes, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/1757 From coleenp at openjdk.java.net Tue Dec 15 17:32:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 17:32:03 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Message-ID: See bug for details. Tested: $ java -XX:+StressLdcRewrite -version Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. Error: The unlock option must precede 'StressLdcRewrite'. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version openjdk version "16-internal" 2021-03-16 OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. ------------- Commit messages: - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option - 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Changes: https://git.openjdk.java.net/jdk/pull/1783/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1783&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257726 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1783.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1783/head:pull/1783 PR: https://git.openjdk.java.net/jdk/pull/1783 From lfoltan at openjdk.java.net Tue Dec 15 17:41:54 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 15 Dec 2020 17:41:54 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <87wL9V1rsGxYFAap1lQsYtmcZJ5wbT28lcRma4HjIlk=.abb73ef7-86c8-4785-b063-622efc3accf7@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Looks good Coleen. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From gziemski at openjdk.java.net Tue Dec 15 17:48:13 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 15 Dec 2020 17:48:13 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() [v2] In-Reply-To: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: change get_signal_handler to take pass by reference attribute ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1680/files - new: https://git.openjdk.java.net/jdk/pull/1680/files/123acb47..aedc4cd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1680&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1680&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1680/head:pull/1680 PR: https://git.openjdk.java.net/jdk/pull/1680 From gziemski at openjdk.java.net Tue Dec 15 17:50:58 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 15 Dec 2020 17:50:58 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() [v2] In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Sat, 12 Dec 2020 07:32:30 GMT, Thomas Stuefe wrote: >> Thank you Thomas for the review. >> >> How about: >> >> `static address get_signal_handler(struct sigaction &action)` >> >> ? > > Meh. I am not a big fan of references :) since at the call site they are indistinguishable from by-value parameters. But if you use them, please make them const. I checked the existing code and decided to use the `get_signal_handler(const struct sigaction* action)` type after all, as that's what all other functions, except for one, use. ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From stuefe at openjdk.java.net Tue Dec 15 17:56:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 17:56:55 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Looks right to me, and trivial. This should not be a product option. I cannot believe anyone uses this option in earnest in production. Still, out of sheer fascination I googled but did not find any serious usage. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From stuefe at openjdk.java.net Tue Dec 15 17:58:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 17:58:00 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() [v2] In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Tue, 15 Dec 2020 17:48:13 GMT, Gerard Ziemski wrote: >> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > change get_signal_handler to take pass by reference attribute Looks good now! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1680 From coleenp at openjdk.java.net Tue Dec 15 20:42:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 20:42:57 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:54:05 GMT, Thomas Stuefe wrote: > I cannot believe anyone uses this option in earnest in production. Still, out of sheer fascination I googled but did not find any serious usage. I discussed this with @dcubed-ojdk who added this for a customer situation and this was his request. Thanks for the code review. Coleen ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From martin.doerr at sap.com Tue Dec 15 20:49:45 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Dec 2020 20:49:45 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Message-ID: Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin From minqi at openjdk.java.net Tue Dec 15 21:18:02 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Dec 2020 21:18:02 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <37HcgNwgzId0EjrtwwFP3FXaGMPgVoRF1WLDsFgu8ok=.6db8f6f1-2da2-4120-bfa2-364410bed549@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. jvmtiRedfineClasses.cpp use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From iklam at openjdk.java.net Tue Dec 15 21:37:05 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Dec 2020 21:37:05 GMT Subject: RFR: 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp Message-ID: Please review this trivial fix for mach5 tier1 build failure: test/hotspot/gtest/runtime/test_os.cpp:525:39: error: cannot convert 'const MEMFLAGS' to 'bool' char* p = os::reserve_memory(1 * M, mtInternal); ^^^^^^^^^^ It's caused by the following change in [os.hpp](url) in [JDK-8234930](https://bugs.openjdk.java.net/browse/JDK-8234930): - static char* reserve_memory(size_t bytes, MEMFLAGS flags = mtOther); + static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther); I am running a personal tier1 job to validate this fix. ------------- Commit messages: - 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp Changes: https://git.openjdk.java.net/jdk/pull/1788/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1788&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258438 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1788.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1788/head:pull/1788 PR: https://git.openjdk.java.net/jdk/pull/1788 From dcubed at openjdk.java.net Tue Dec 15 21:37:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 15 Dec 2020 21:37:05 GMT Subject: RFR: 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp In-Reply-To: References: Message-ID: <_1VwE4ICAngHPKS8o5unOpGONxGOXx644yFCRC7QIv4=.e088e500-3780-4d13-aa6c-dd22a8b3874a@github.com> On Tue, 15 Dec 2020 21:26:48 GMT, Ioi Lam wrote: > Please review this trivial fix for mach5 tier1 build failure: > > test/hotspot/gtest/runtime/test_os.cpp:525:39: error: cannot convert 'const MEMFLAGS' to 'bool' > char* p = os::reserve_memory(1 * M, mtInternal); > ^^^^^^^^^^ > > It's caused by the following change in [os.hpp](url) in [JDK-8234930](https://bugs.openjdk.java.net/browse/JDK-8234930): > > - static char* reserve_memory(size_t bytes, MEMFLAGS flags = mtOther); > + static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther); > > I am running a personal tier1 job to validate this fix. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1788 From tschatzl at openjdk.java.net Tue Dec 15 21:37:05 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Dec 2020 21:37:05 GMT Subject: RFR: 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:26:48 GMT, Ioi Lam wrote: > Please review this trivial fix for mach5 tier1 build failure: > > test/hotspot/gtest/runtime/test_os.cpp:525:39: error: cannot convert 'const MEMFLAGS' to 'bool' > char* p = os::reserve_memory(1 * M, mtInternal); > ^^^^^^^^^^ > > It's caused by the following change in [os.hpp](url) in [JDK-8234930](https://bugs.openjdk.java.net/browse/JDK-8234930): > > - static char* reserve_memory(size_t bytes, MEMFLAGS flags = mtOther); > + static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther); > > I am running a personal tier1 job to validate this fix. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1788 From iklam at openjdk.java.net Tue Dec 15 21:44:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Dec 2020 21:44:55 GMT Subject: RFR: 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:33:49 GMT, Thomas Schatzl wrote: >> Please review this trivial fix for mach5 tier1 build failure: >> >> test/hotspot/gtest/runtime/test_os.cpp:525:39: error: cannot convert 'const MEMFLAGS' to 'bool' >> char* p = os::reserve_memory(1 * M, mtInternal); >> ^^^^^^^^^^ >> >> It's caused by the following change in [os.hpp](url) in [JDK-8234930](https://bugs.openjdk.java.net/browse/JDK-8234930): >> >> - static char* reserve_memory(size_t bytes, MEMFLAGS flags = mtOther); >> + static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther); >> >> I am running a personal tier1 job to validate this fix. > > Marked as reviewed by tschatzl (Reviewer). My local build passed. Since all tier1 builds had failed due to this bug, I'll integrate now. It can't make things any worse. Thanks @dcubed-ojdk and @tschatzl for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1788 From iklam at openjdk.java.net Tue Dec 15 21:44:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Dec 2020 21:44:56 GMT Subject: Integrated: 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:26:48 GMT, Ioi Lam wrote: > Please review this trivial fix for mach5 tier1 build failure: > > test/hotspot/gtest/runtime/test_os.cpp:525:39: error: cannot convert 'const MEMFLAGS' to 'bool' > char* p = os::reserve_memory(1 * M, mtInternal); > ^^^^^^^^^^ > > It's caused by the following change in [os.hpp](url) in [JDK-8234930](https://bugs.openjdk.java.net/browse/JDK-8234930): > > - static char* reserve_memory(size_t bytes, MEMFLAGS flags = mtOther); > + static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther); > > I am running a personal tier1 job to validate this fix. This pull request has now been integrated. Changeset: 8bf46c73 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/8bf46c73 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8258438: build error in test/hotspot/gtest/runtime/test_os.cpp Reviewed-by: dcubed, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1788 From coleenp at openjdk.java.net Tue Dec 15 21:46:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 21:46:04 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code Message-ID: This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hash code because it's the same hashcode as the dictionary hashcode. There's are some assert for this. One of the find_class() functions is redundant to dictionary->find_class() so is removed. Tested with tier1-6. ------------- Commit messages: - 8258048: Placeholder hash code is the same as Dictionary hash code Changes: https://git.openjdk.java.net/jdk/pull/1789/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1789&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258048 Stats: 129 lines in 8 files changed: 6 ins; 31 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/1789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1789/head:pull/1789 PR: https://git.openjdk.java.net/jdk/pull/1789 From ccheung at openjdk.java.net Tue Dec 15 23:16:11 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 15 Dec 2020 23:16:11 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive Message-ID: Please review this change for JDK 16. In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. Passed tiers 1,2,3,4 tests. ------------- Commit messages: - 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive Changes: https://git.openjdk.java.net/jdk16/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258236 Stats: 191 lines in 4 files changed: 191 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/30/head:pull/30 PR: https://git.openjdk.java.net/jdk16/pull/30 From redestad at openjdk.java.net Tue Dec 15 23:28:02 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 15 Dec 2020 23:28:02 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:08:42 GMT, Calvin Cheung wrote: > Please review this change for JDK 16. > > In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. > > Passed tiers 1,2,3,4 tests. Fix and tests looks good! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/30 From coleenp at openjdk.java.net Tue Dec 15 23:43:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:43:04 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:08:42 GMT, Calvin Cheung wrote: > Please review this change for JDK 16. > > In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. > > Passed tiers 1,2,3,4 tests. Changes requested by coleenp (Reviewer). src/hotspot/share/classfile/classListParser.cpp line 474: > 472: return; > 473: } > 474: MetaspaceShared::try_link_class(ik, THREAD); Doesn't the check for failing verification belong after try_link_class(), which runs the verifier? src/hotspot/share/classfile/classListParser.cpp line 467: > 465: Handle class_loader(THREAD, SystemDictionary::java_system_loader()); > 466: Handle protection_domain; > 467: Klass* klass = SystemDictionary::resolve_or_fail(class_name_symbol, class_loader, protection_domain, true, THREAD); // FIXME should really be just a lookup If an exception is unexpected, this should be CHECK not THREAD. ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From dcubed at openjdk.java.net Tue Dec 15 23:43:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 15 Dec 2020 23:43:54 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1783 From dholmes at openjdk.java.net Tue Dec 15 23:44:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 15 Dec 2020 23:44:58 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() [v2] In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Tue, 15 Dec 2020 17:48:13 GMT, Gerard Ziemski wrote: >> This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > change get_signal_handler to take pass by reference attribute Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1680 From coleenp at openjdk.java.net Tue Dec 15 23:57:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:57:57 GMT Subject: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:41:31 GMT, Daniel D. Daugherty wrote: >> See bug for details. Tested: >> >> $ java -XX:+StressLdcRewrite -version >> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. >> Error: The unlock option must precede 'StressLdcRewrite'. >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version >> openjdk version "16-internal" 2021-03-16 >> OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) >> OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) >> >> Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. > > Thumbs up! Thanks Lois, Thomas and Dan. ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From coleenp at openjdk.java.net Tue Dec 15 23:57:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:57:58 GMT Subject: Integrated: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option In-Reply-To: References: Message-ID: <6ULIw61aH0yasVbStN371CTQd0xy8LiK8fgYj0Zv8bw=.558bc893-e181-4e65-8fe6-4fc49752e534@github.com> On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRewrite'. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -XX:+UnlockDiagnosticVMOptions -XX:+StressLdcRewrite -version > openjdk version "16-internal" 2021-03-16 > OpenJDK Runtime Environment (build 16-internal+0-2020-12-15-1356558.coleen...) > OpenJDK 64-Bit Server VM (build 16-internal+0-2020-12-15-1356558.coleen..., mixed mode, sharing) > > Also, java/lang/instrument which has a test using StressLdcRewrite and tier1. This pull request has now been integrated. Changeset: 4d6f3181 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/4d6f3181 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod 8257726: Make -XX:+StressLdcRewrite option a diagnostic option Reviewed-by: lfoltan, stuefe, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1783 From dholmes at openjdk.java.net Wed Dec 16 00:02:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 00:02:58 GMT Subject: Integrated: 8236225: Remove expired flags in JDK 17 In-Reply-To: References: Message-ID: <4du3cZBi7vkR_Fm7I_0QV2U42l7pTthzyMKDQBdIq10=.aba1f5ea-7d04-44b9-8545-00a5a1a540a7@github.com> On Mon, 14 Dec 2020 22:43:16 GMT, David Holmes wrote: > 8236225: Remove expired flags in JDK 17 > 8256717: Expire the long term obsoleted VM flags > > The newly expired flags in 17 are removed from the flag table, as are all of the long term obsolete flags that had no explicit expiration release. > > Updated any remaining references to the obsolete flags that are now expired. > > Updated the man page to move flags from obsolete section to expired (removed) section. Note the manpage also shows changes to the illegal-access flag, this is a change that was made to the closed manpage source for JDK 16 but has not yet been pushed into the open java.1 version. This part of the change can be ignored. > > Testing: tiers 1-3 and local testing of modified tests. I'm also checking for any JCK tests that may still use the legacy obsolete flags. > > Thanks, > David This pull request has now been integrated. Changeset: 1e778968 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/1e778968 Stats: 341 lines in 7 files changed: 118 ins; 213 del; 10 mod 8236225: Remove expired flags in JDK 17 8256717: Expire the long term obsoleted VM flags Reviewed-by: coleenp, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1773 From dholmes at openjdk.java.net Wed Dec 16 01:09:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 01:09:57 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:41:40 GMT, Coleen Phillimore wrote: > This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. > > One of the find_class() functions is redundant to dictionary->find_class() so is removed. > > Tested with tier1-6. Hi Coleen, This all looks good to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1789 From coleenp at openjdk.java.net Wed Dec 16 01:14:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 01:14:56 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 01:07:21 GMT, David Holmes wrote: >> This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. >> >> One of the find_class() functions is redundant to dictionary->find_class() so is removed. >> >> Tested with tier1-6. > > Hi Coleen, > This all looks good to me. > Thanks, > David Thanks, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/1789 From ccheung at openjdk.java.net Wed Dec 16 01:18:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 16 Dec 2020 01:18:56 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: <0p24MC0M4umETzKZWdHsRUIVF5HhpzD-5mpwVvPfnmI=.839097d0-a67c-48d5-a876-b9f1b37f5a1e@github.com> On Tue, 15 Dec 2020 23:24:48 GMT, Claes Redestad wrote: > Fix and tests looks good! @cl4es Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From ccheung at openjdk.java.net Wed Dec 16 01:18:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 16 Dec 2020 01:18:59 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: <2q8lGYdgA7i17s9oD6Gxu0pUV_K_xZeFh-rCPbMhQNs=.14cdfcc0-d7b3-4cb0-9780-5acc5a576f5d@github.com> On Tue, 15 Dec 2020 23:39:04 GMT, Coleen Phillimore wrote: >> Please review this change for JDK 16. >> >> In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. >> >> Passed tiers 1,2,3,4 tests. > > src/hotspot/share/classfile/classListParser.cpp line 474: > >> 472: return; >> 473: } >> 474: MetaspaceShared::try_link_class(ik, THREAD); > > Doesn't the check for failing verification belong after try_link_class(), which runs the verifier? Linking attempt was done for the class and was marked as failed verification prior to getting into `ClassListParser::resolve_indy`. Consider the following class list (from the test case): BadInvokeDynamic @lambda-proxy BadInvokeDynamic run ()Ljava/lang/Runnable; ()V REF_invokeStatic BadInvokeDynamic lambda$doTest$0 ()V ()V The BadInvokeDynamic was linked via the following code path: MetaspaceShared::try_link_class() at metaspaceShared.cpp:1,161 0x7ffff63b1c10 MetaspaceShared::preload_classes() at metaspaceShared.cpp:1,125 0x7ffff63b1a42 MetaspaceShared::preload_and_dump() at metaspaceShared.cpp:1,047 0x7ffff63b1557 Threads::create_vm() at thread.cpp:3,809 0x7ffff666b3f9 JNI_CreateJavaVM_inner() at jni.cpp:3,769 0x7ffff604b1be JNI_CreateJavaVM() at jni.cpp:3,852 0x7ffff604b4c3 InitializeJVM() at java.c:1,536 0x7ffff7fcd664 JavaMain() at java.c:416 0x7ffff7fca252 ThreadJavaMain() at java_md.c:651 0x7ffff7fd0f77 start_thread() at 0x7ffff79b0ea5 It was marked as failed verification in `MetaspaceShared::try_link_class` in the following: ik->link_class(THREAD); if (HAS_PENDING_EXCEPTION) { ResourceMark rm(THREAD); log_warning(cds)("Preload Warning: Verification failed for %s", ik->external_name()); CLEAR_PENDING_EXCEPTION; SystemDictionaryShared::set_class_has_failed_verification(ik); _has_error_classes = true; } During the processing of the `@lambda-proxy` in the class list, the `ClassListParser::resolve_indy` would be called and the check is for checking if the caller class has failed verification before. > src/hotspot/share/classfile/classListParser.cpp line 467: > >> 465: Handle class_loader(THREAD, SystemDictionary::java_system_loader()); >> 466: Handle protection_domain; >> 467: Klass* klass = SystemDictionary::resolve_or_fail(class_name_symbol, class_loader, protection_domain, true, THREAD); // FIXME should really be just a lookup > > If an exception is unexpected, this should be CHECK not THREAD. I'll try CHECK and do more testing before posting an updated webrev. Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From coleenp at openjdk.java.net Wed Dec 16 01:34:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 01:34:58 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: <2q8lGYdgA7i17s9oD6Gxu0pUV_K_xZeFh-rCPbMhQNs=.14cdfcc0-d7b3-4cb0-9780-5acc5a576f5d@github.com> References: <2q8lGYdgA7i17s9oD6Gxu0pUV_K_xZeFh-rCPbMhQNs=.14cdfcc0-d7b3-4cb0-9780-5acc5a576f5d@github.com> Message-ID: On Wed, 16 Dec 2020 01:15:07 GMT, Calvin Cheung wrote: >> src/hotspot/share/classfile/classListParser.cpp line 467: >> >>> 465: Handle class_loader(THREAD, SystemDictionary::java_system_loader()); >>> 466: Handle protection_domain; >>> 467: Klass* klass = SystemDictionary::resolve_or_fail(class_name_symbol, class_loader, protection_domain, true, THREAD); // FIXME should really be just a lookup >> >> If an exception is unexpected, this should be CHECK not THREAD. > > I'll try CHECK and do more testing before posting an updated webrev. > > Thanks for your review. For this change, don't change it to CHECK in case something new will fail, and any new exceptions will caught by checking k != NULL. It just looks strange but can be cleaned up later. >> src/hotspot/share/classfile/classListParser.cpp line 474: >> >>> 472: return; >>> 473: } >>> 474: MetaspaceShared::try_link_class(ik, THREAD); >> >> Doesn't the check for failing verification belong after try_link_class(), which runs the verifier? > > Linking attempt was done for the class and was marked as failed verification prior to getting into `ClassListParser::resolve_indy`. > > Consider the following class list (from the test case): > BadInvokeDynamic > @lambda-proxy BadInvokeDynamic run ()Ljava/lang/Runnable; ()V REF_invokeStatic BadInvokeDynamic lambda$doTest$0 ()V ()V > > The BadInvokeDynamic was linked via the following code path: > MetaspaceShared::try_link_class() at metaspaceShared.cpp:1,161 0x7ffff63b1c10 > MetaspaceShared::preload_classes() at metaspaceShared.cpp:1,125 0x7ffff63b1a42 > MetaspaceShared::preload_and_dump() at metaspaceShared.cpp:1,047 0x7ffff63b1557 > Threads::create_vm() at thread.cpp:3,809 0x7ffff666b3f9 > JNI_CreateJavaVM_inner() at jni.cpp:3,769 0x7ffff604b1be > JNI_CreateJavaVM() at jni.cpp:3,852 0x7ffff604b4c3 > InitializeJVM() at java.c:1,536 0x7ffff7fcd664 > JavaMain() at java.c:416 0x7ffff7fca252 > ThreadJavaMain() at java_md.c:651 0x7ffff7fd0f77 > start_thread() at 0x7ffff79b0ea5 > > It was marked as failed verification in `MetaspaceShared::try_link_class` in the following: > ik->link_class(THREAD); > if (HAS_PENDING_EXCEPTION) { > ResourceMark rm(THREAD); > log_warning(cds)("Preload Warning: Verification failed for %s", > ik->external_name()); > CLEAR_PENDING_EXCEPTION; > SystemDictionaryShared::set_class_has_failed_verification(ik); > _has_error_classes = true; > } > During the processing of the `@lambda-proxy` in the class list, the `ClassListParser::resolve_indy` would be called and the check is for checking if the caller class has failed verification before. Okay so you're trying to catch a previous link time failure. Why do you expect the next try_link_class call to never fail? ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From coleenp at openjdk.java.net Wed Dec 16 01:34:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 01:34:55 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:08:42 GMT, Calvin Cheung wrote: > Please review this change for JDK 16. > > In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. > > Passed tiers 1,2,3,4 tests. I just have questions. The change as-is is good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/30 From ccheung at openjdk.java.net Wed Dec 16 02:32:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 16 Dec 2020 02:32:56 GMT Subject: [jdk16] RFR: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: <37hDBBRIBt4-LWUQdgpiPxCI2HDB-xBjpQEANxVmKFY=.ac1ede24-13d3-4305-bea5-ca501a2d2954@github.com> On Wed, 16 Dec 2020 01:31:44 GMT, Coleen Phillimore wrote: >> Please review this change for JDK 16. >> >> In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. >> >> Passed tiers 1,2,3,4 tests. > > I just have questions. The change as-is is good. >For this change, don't change it to CHECK in case something new will fail, and any new exceptions will caught by checking k != NULL. It just looks strange but can be cleaned up later. I was thinking the same - do the clean up later. Initial local testing looks good - no new cds/appcds tests failure. >Okay so you're trying to catch a previous link time failure. Why do you expect the next try_link_class call to never fail? Previous link time failure was recorded via `SystemDictionaryShared::set_class_has_failed_verification(ik)`. `try_link_class` will not result in an exception because there's a `if (HAS_PENDING_EXCEPTION)` block which calls `CLEAR_PENDING_EXCEPTION`. ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From ccheung at openjdk.java.net Wed Dec 16 02:41:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 16 Dec 2020 02:41:59 GMT Subject: [jdk16] Integrated: 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:08:42 GMT, Calvin Cheung wrote: > Please review this change for JDK 16. > > In ClassListParser::resolve_indy, if a class has previously failed verification, don't proceed with resolve indy for that class to avoid dereferencing a null cpcache pointer. > > Passed tiers 1,2,3,4 tests. This pull request has now been integrated. Changeset: b5a3a5b6 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk16/commit/b5a3a5b6 Stats: 191 lines in 4 files changed: 191 ins; 0 del; 0 mod 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive Reviewed-by: redestad, coleenp ------------- PR: https://git.openjdk.java.net/jdk16/pull/30 From richard.reingruber at sap.com Wed Dec 16 10:54:07 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 16 Dec 2020 10:54:07 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi Martin, I've compared the proposed change for 11u with the original change. It looks good to me. Thanks, Richard. -----Original Message----- From: hotspot-runtime-dev On Behalf Of Doerr, Martin Sent: Dienstag, 15. Dezember 2020 21:50 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin From martin.doerr at sap.com Wed Dec 16 11:03:02 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Dec 2020 11:03:02 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi Richard, thanks for reviewing! Best regards, Martin > -----Original Message----- > From: Reingruber, Richard > Sent: Mittwoch, 16. Dezember 2020 11:54 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Hi Martin, > > I've compared the proposed change for 11u with the original change. It looks > good to me. > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Doerr, Martin > Sent: Dienstag, 15. Dezember 2020 21:50 > To: hotspot-runtime-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to > take a more complex type than ThreadClosure > > Hi, > > JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. > It's only a refactoring. > Unfortunately, it doesn't apply cleanly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234796 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ > > Resolution steps: > - Manually integrated includes, forward declarations and Copyright updates > due to different context. > - Handshake operations (handshake.cpp): Removed _executed field from > patch which was added by JDK-8191890 which is not in 11u. > - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK- > 8191890 which is not in 11u. > - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK- > 8226705 which is not in 11u. > - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 > which is not in 11u. > - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of > JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later > due to problems). > - Skipped "ShenandoahUnloadRendezvousClosure" and > "ZRendezvousClosure" which don't exist in 11u at all. > > (Also uploaded here with complete listing of non-automatically applied > hunks: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_han > dshake_integration.txt) > > Please review. > > Best regards, > Martin From coleenp at openjdk.java.net Wed Dec 16 13:10:11 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 13:10:11 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v2] In-Reply-To: References: Message-ID: > This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. > > One of the find_class() functions is redundant to dictionary->find_class() so is removed. > > Tested with tier1-6. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into class-loading - 8258048: Placeholder hash code is the same as Dictionary hash code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1789/files - new: https://git.openjdk.java.net/jdk/pull/1789/files/0071785f..ddf96fa2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1789&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1789&range=00-01 Stats: 1778 lines in 52 files changed: 906 ins; 756 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/1789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1789/head:pull/1789 PR: https://git.openjdk.java.net/jdk/pull/1789 From ysuenaga at openjdk.java.net Wed Dec 16 13:11:05 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 13:11:05 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work Message-ID: `search codecache` command does not work as following: hsdb> search codecache 0x7fedbd0aec90 java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. SA should support `VtableBlob`. ------------- Commit messages: - 8258471: "search codecache" clhsdb command does not work Changes: https://git.openjdk.java.net/jdk/pull/1800/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1800&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258471 Stats: 47 lines in 3 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1800/head:pull/1800 PR: https://git.openjdk.java.net/jdk/pull/1800 From hseigel at openjdk.java.net Wed Dec 16 14:45:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 16 Dec 2020 14:45:57 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 13:10:11 GMT, Coleen Phillimore wrote: >> This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. >> >> One of the find_class() functions is redundant to dictionary->find_class() so is removed. >> >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into class-loading > - 8258048: Placeholder hash code is the same as Dictionary hash code Changes look good. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1789 From lfoltan at openjdk.java.net Wed Dec 16 15:16:03 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 16 Dec 2020 15:16:03 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 13:10:11 GMT, Coleen Phillimore wrote: >> This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. >> >> One of the find_class() functions is redundant to dictionary->find_class() so is removed. >> >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into class-loading > - 8258048: Placeholder hash code is the same as Dictionary hash code Nice cleanup Coleen! Lois src/hotspot/share/classfile/placeholders.cpp line 133: > 131: Symbol* supername, > 132: Thread* thread) { > 133: PlaceholderEntry* probe = get_entry(hash, name, loader_data); Minor nit of a comment since you are in this file and specifically in this method can you consider changing the if statement conditional at line #143 to explicitly check if (probe != NULL)? I noticed line #167 has this type of conditional and it would be good to have consistency. I think there are some other cases in this file, like line #119, where it is inconsistent. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1789 From coleenp at openjdk.java.net Wed Dec 16 16:48:16 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 16:48:16 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v3] In-Reply-To: References: Message-ID: > This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. > > One of the find_class() functions is redundant to dictionary->find_class() so is removed. > > Tested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix or remove extraneous null checks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1789/files - new: https://git.openjdk.java.net/jdk/pull/1789/files/ddf96fa2..0ec6dc91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1789&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1789&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1789/head:pull/1789 PR: https://git.openjdk.java.net/jdk/pull/1789 From coleenp at openjdk.java.net Wed Dec 16 17:00:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 17:00:00 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 15:13:42 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into class-loading >> - 8258048: Placeholder hash code is the same as Dictionary hash code > > Nice cleanup Coleen! > Lois I took out some extra header file includes and fixed or removed some null checks. I'm rerunning sanity checks (tier1 on linux-x64, macosx-64, windows-x64 and linux-aarch64). Also cross compiled for ppc, arm, s390 and zero. Changing include files can be dangerous. I also reran jck lang and vm tests. > src/hotspot/share/classfile/placeholders.cpp line 133: > >> 131: Symbol* supername, >> 132: Thread* thread) { >> 133: PlaceholderEntry* probe = get_entry(hash, name, loader_data); > > Minor nit of a comment since you are in this file and specifically in this method can you consider changing the if statement conditional at line #143 to explicitly check if (probe != NULL)? I noticed line #167 has this type of conditional and it would be good to have consistency. I think there are some other cases in this file, like line #119, where it is inconsistent. The if (probe) conditional on line #143 isn't necessary because we've just created a placeholder and code above would have null pointer references if it failed (in add_entry -> new_entry), so I removed it. I fixed another check against NULL just above this. I don't see any others here at least. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1789 From gziemski at openjdk.java.net Wed Dec 16 17:12:59 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 16 Dec 2020 17:12:59 GMT Subject: Integrated: 8251438: Issues with our POSIX set_signal_handler() In-Reply-To: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Mon, 7 Dec 2020 21:45:57 GMT, Gerard Ziemski wrote: > This is a fix for a potential issue involving "The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously." https://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html, when we in fact do assume different storages. This pull request has now been integrated. Changeset: 70183f4d Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/70183f4d Stats: 26 lines in 1 file changed: 11 ins; 10 del; 5 mod 8251438: Issues with our POSIX set_signal_handler() Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From gziemski at openjdk.java.net Wed Dec 16 17:37:57 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 16 Dec 2020 17:37:57 GMT Subject: RFR: 8251438: Issues with our POSIX set_signal_handler() [v2] In-Reply-To: References: <3Nnhcahr61_S9BgurmSWH2_cDcghAzkeJSqUmjbysJg=.98c04c98-4d00-4a05-886b-70d2284dd931@github.com> Message-ID: On Tue, 15 Dec 2020 23:42:27 GMT, David Holmes wrote: >> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: >> >> change get_signal_handler to take pass by reference attribute > > Looks good. > Thanks, > David Thank you David and Thomas for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1680 From lfoltan at openjdk.java.net Wed Dec 16 19:14:59 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 16 Dec 2020 19:14:59 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v3] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 16:48:16 GMT, Coleen Phillimore wrote: >> This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. >> >> One of the find_class() functions is redundant to dictionary->find_class() so is removed. >> >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix or remove extraneous null checks. Thank you for making suggested changes. Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1789 From coleenp at openjdk.java.net Wed Dec 16 19:22:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 19:22:01 GMT Subject: RFR: 8258048: Placeholder hash code is the same as Dictionary hash code [v3] In-Reply-To: References: Message-ID: <6LwM755BUjcgFe8OdrlnZOv5WkKUqNTrFAKvnPCMysE=.9ca087e7-be7f-4c6e-9176-13adacd64d86@github.com> On Wed, 16 Dec 2020 19:12:13 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix or remove extraneous null checks. > > Thank you for making suggested changes. Looks good. > Lois Thanks for the rereview, Lois. Sanity tests now passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1789 From coleenp at openjdk.java.net Wed Dec 16 19:22:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 19:22:03 GMT Subject: Integrated: 8258048: Placeholder hash code is the same as Dictionary hash code In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:41:40 GMT, Coleen Phillimore wrote: > This change is a set of cleanups to the placeholders hashtable. It moves the index calculation inside the hashtable. It avoids using the placeholder hashcode because it's the same hashcode as the dictionary hashcode. There are some asserts for this. > > One of the find_class() functions is redundant to dictionary->find_class() so is removed. > > Tested with tier1-6. This pull request has now been integrated. Changeset: c4632647 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/c4632647 Stats: 134 lines in 8 files changed: 6 ins; 32 del; 96 mod 8258048: Placeholder hash code is the same as Dictionary hash code Reviewed-by: dholmes, hseigel, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1789 From dgriffiths at undo.io Wed Dec 16 20:01:58 2020 From: dgriffiths at undo.io (David Griffiths) Date: Wed, 16 Dec 2020 20:01:58 +0000 Subject: InterpretedVFrame.getExpressions Message-ID: I'm guessing nobody uses InterpretedVFrame.getExpressions? Appears quite broken - getInterpreterFrameExpressionStackSize returning a negative byte offset. Cheers, David -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis From coleenp at openjdk.java.net Thu Dec 17 00:42:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 00:42:03 GMT Subject: RFR: 8258415: gtest for committed memory leaks reservation Message-ID: Add a call to os::release_memory() in the gtest. Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. ------------- Commit messages: - 8258415: gtest for committed memory leaks reservation Changes: https://git.openjdk.java.net/jdk/pull/1809/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1809&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258415 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1809.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1809/head:pull/1809 PR: https://git.openjdk.java.net/jdk/pull/1809 From cjplummer at openjdk.java.net Thu Dec 17 05:54:55 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:54:55 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1800 From stuefe at openjdk.java.net Thu Dec 17 06:12:25 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Dec 2020 06:12:25 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale [v4] In-Reply-To: References: Message-ID: > The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. > > Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. > > Background: > > The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. > > This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. > > That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. > > But it messes up statistics a bit. Example: > > jcmd xxx VM.metaspace > > > > Chunk freelists: > > Both: > > 4m: (none) > 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) > 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) > 512k: (none) > 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed > 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 5,83 MB, committed: 0 bytes ( 0%) > > > In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. > > The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: > > Both: > > 4m: (none) > 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) > 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) > 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) > 256k: (none) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good > 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 8,78 MB, committed: 96,00 KB ( 1%) > > Thanks, Thomas Thomas Stuefe 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: - Fix death test - Merge - Add an assert to make chunk-to-granule-geometry explicit - Merge - Add gtest for Vsn::is_range_fully_committed - Initial ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1291/files - new: https://git.openjdk.java.net/jdk/pull/1291/files/205425e8..901d42ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=02-03 Stats: 68824 lines in 1566 files changed: 50262 ins; 11937 del; 6625 mod Patch: https://git.openjdk.java.net/jdk/pull/1291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1291/head:pull/1291 PR: https://git.openjdk.java.net/jdk/pull/1291 From dholmes at openjdk.java.net Thu Dec 17 11:54:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Dec 2020 11:54:12 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 Message-ID: The fix in JDK-8193234 had an unintended consequence for the ReleaseArrayElements API, which is now fixed in this issue. I'd like to thank Mauro Lacy and Dmitry Timofeev for raising, analysing and discussing this issue. You can follow the thread here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/047248.html Although the fix itself is very basic I found a couple of other issues along the way, so I have staged the commits as follows for ease of understanding: Step 1: added a regression test for the current double-free problem Step 2: Only try to print the GuardedMemory info in debug builds as it can lead to secondary crashes Step 3: Fix incorrect function names in the error messages and cleanup formatting Step 4: Revert the change from JDK-8193234 Step 5: Add the memory-leak test from JDK-8193234 as a manual test Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical Finally I had to tweak the test to fix a nativepath problem. Testing: - tiers 1-4 (tier 4 includes the test run with -Xcheck:jni) - local testing of the new tests Thanks, David ------------- Commit messages: - Updated test to fix nativepath problem. - Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical - Step 5: Add the memory-leak test from JDK-8193234 as a manual test - Step 4: Revert the change from JDK-8193234 - Step 3: Fix incorrect function names in the error messages and cleanup formatting. - Step 2: Only try to print the GuardedMemory info in debug builds as it can trigger a secondary crash. - 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 Changes: https://git.openjdk.java.net/jdk/pull/1816/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1816&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258077 Stats: 321 lines in 5 files changed: 303 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1816/head:pull/1816 PR: https://git.openjdk.java.net/jdk/pull/1816 From lzang at openjdk.java.net Thu Dec 17 13:16:02 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 17 Dec 2020 13:16:02 GMT Subject: RFR: 8258593: remove redundant codes in HeapObjectDumper Message-ID: 8258593: remove redundant codes in HeapObjectDumper ------------- Commit messages: - 8258593: remove redundant codes in HeapObjectDumper Changes: https://git.openjdk.java.net/jdk/pull/1819/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1819&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258593 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1819.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1819/head:pull/1819 PR: https://git.openjdk.java.net/jdk/pull/1819 From coleenp at openjdk.java.net Thu Dec 17 13:21:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:21:57 GMT Subject: RFR: 8258593: remove redundant codes in HeapObjectDumper In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 13:10:51 GMT, Lin Zang wrote: > 8258593: remove redundant codes in HeapObjectDumper Nice cleanup! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1819 From hseigel at openjdk.java.net Thu Dec 17 13:23:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 17 Dec 2020 13:23:57 GMT Subject: RFR: 8258415: gtest for committed memory leaks reservation In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:37:00 GMT, Coleen Phillimore wrote: > Add a call to os::release_memory() in the gtest. > Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. Changes look good and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1809 From stuefe at openjdk.java.net Thu Dec 17 13:30:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Dec 2020 13:30:55 GMT Subject: RFR: 8258415: gtest for committed memory leaks reservation In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:37:00 GMT, Coleen Phillimore wrote: > Add a call to os::release_memory() in the gtest. > Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1809 From coleenp at openjdk.java.net Thu Dec 17 13:30:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:30:57 GMT Subject: RFR: 8258415: gtest for committed memory leaks reservation In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 13:21:27 GMT, Harold Seigel wrote: >> Add a call to os::release_memory() in the gtest. >> Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. > > Changes look good and trivial. > Harold Thanks Harold. ------------- PR: https://git.openjdk.java.net/jdk/pull/1809 From coleenp at openjdk.java.net Thu Dec 17 13:37:54 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:37:54 GMT Subject: RFR: 8258415: gtest for committed memory leaks reservation In-Reply-To: References: Message-ID: <62HOZRTtfoq3I10rJOLtVWXmQSeyOwMGlrIBQz9o-Q8=.e9489170-f307-4066-a72b-95098b93f093@github.com> On Thu, 17 Dec 2020 13:28:40 GMT, Thomas Stuefe wrote: >> Add a call to os::release_memory() in the gtest. >> Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. > > +1 Thanks Thomas! ------------- PR: https://git.openjdk.java.net/jdk/pull/1809 From coleenp at openjdk.java.net Thu Dec 17 13:37:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:37:56 GMT Subject: Integrated: 8258415: gtest for committed memory leaks reservation In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:37:00 GMT, Coleen Phillimore wrote: > Add a call to os::release_memory() in the gtest. > Tested with gtest on linux-x64-debug. tier1 testing in progress to run on other platforms. This pull request has now been integrated. Changeset: 6aa8eed3 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/6aa8eed3 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8258415: gtest for committed memory leaks reservation Reviewed-by: hseigel, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1809 From lfoltan at openjdk.java.net Thu Dec 17 15:39:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 17 Dec 2020 15:39:57 GMT Subject: RFR: 8258593: remove redundant codes in HeapObjectDumper In-Reply-To: References: Message-ID: <8NK6nMy1yL5jK04VuUjxrms0n8UdUcEgBOP1REBSUDQ=.f13d7ff9-41c1-418d-b63a-632fdf652b46@github.com> On Thu, 17 Dec 2020 13:10:51 GMT, Lin Zang wrote: > 8258593: remove redundant codes in HeapObjectDumper LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1819 From goetz.lindenmaier at sap.com Thu Dec 17 17:20:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 17 Dec 2020 17:20:53 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Looks good to me. Thanks for backporting, and thanks for the detailed description of your changes! Best regards, Goetz. -----Original Message----- From: Reingruber, Richard Sent: Mittwoch, 16. Dezember 2020 11:54 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi Martin, I've compared the proposed change for 11u with the original change. It looks good to me. Thanks, Richard. -----Original Message----- From: hotspot-runtime-dev On Behalf Of Doerr, Martin Sent: Dienstag, 15. Dezember 2020 21:50 To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure Hi, JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. It's only a refactoring. Unfortunately, it doesn't apply cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8234796 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff 11u backport: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ Resolution steps: - Manually integrated includes, forward declarations and Copyright updates due to different context. - Handshake operations (handshake.cpp): Removed _executed field from patch which was added by JDK-8191890 which is not in 11u. - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK-8191890 which is not in 11u. - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK-8226705 which is not in 11u. - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 which is not in 11u. - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later due to problems). - Skipped "ShenandoahUnloadRendezvousClosure" and "ZRendezvousClosure" which don't exist in 11u at all. (Also uploaded here with complete listing of non-automatically applied hunks: http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_handshake_integration.txt) Please review. Best regards, Martin From martin.doerr at sap.com Thu Dec 17 17:50:30 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Dec 2020 17:50:30 +0000 Subject: [11u] RFR: 8234796: Refactor Handshake::execute to take a more complex type than ThreadClosure In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Best regards, Martin > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 17. Dezember 2020 18:21 > To: Reingruber, Richard ; Doerr, Martin > ; hotspot-runtime-dev at openjdk.java.net; jdk- > updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Looks good to me. > > Thanks for backporting, and thanks for the detailed description of your > changes! > > Best regards, > Goetz. > > -----Original Message----- > From: Reingruber, Richard > Sent: Mittwoch, 16. Dezember 2020 11:54 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8234796: Refactor Handshake::execute to take a more > complex type than ThreadClosure > > Hi Martin, > > I've compared the proposed change for 11u with the original change. It looks > good to me. > > Thanks, > Richard. > > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Doerr, Martin > Sent: Dienstag, 15. Dezember 2020 21:50 > To: hotspot-runtime-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: [CAUTION] [11u] RFR: 8234796: Refactor Handshake::execute to > take a more complex type than ThreadClosure > > Hi, > > JDK-8234796 is backported to 11.0.11-oracle. I'd like to backport it for parity. > It's only a refactoring. > Unfortunately, it doesn't apply cleanly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8234796 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/rev/99b71c5b02ff > > 11u backport: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/webrev.00/ > > Resolution steps: > - Manually integrated includes, forward declarations and Copyright updates > due to different context. > - Handshake operations (handshake.cpp): Removed _executed field from > patch which was added by JDK-8191890 which is not in 11u. > - Skipped "RevokeOneBias" (biasedLocking.cpp) which is also part of JDK- > 8191890 which is not in 11u. > - Skipped "DeoptimizeMarkedTC" (deoptimization.cpp) which is part of JDK- > 8226705 which is not in 11u. > - Skipped "HandshakeALotTC" (vmThread.cpp) which is part of JDK-8220774 > which is not in 11u. > - Skipped "NMethodMarkingThreadClosure" (sweeper.cpp) which is part of > JDK-8132849 which is not in 11u (it was in 11.0.8-oracle, but backed out later > due to problems). > - Skipped "ShenandoahUnloadRendezvousClosure" and > "ZRendezvousClosure" which don't exist in 11u at all. > > (Also uploaded here with complete listing of non-automatically applied > hunks: > http://cr.openjdk.java.net/~mdoerr/8234796_handshake_11u/8234796_han > dshake_integration.txt) > > Please review. > > Best regards, > Martin From minqi at openjdk.java.net Thu Dec 17 19:10:02 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Dec 2020 19:10:02 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory Message-ID: Hi, Please review This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). This step remove the function split_reserved_memory which no longer be called after first step. Tests: tier1-4 Thanks Yumin ------------- Commit messages: - 8256213: Remove os::split_reserved_memory Changes: https://git.openjdk.java.net/jdk/pull/1825/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1825&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256213 Stats: 70 lines in 6 files changed: 0 ins; 63 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1825.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1825/head:pull/1825 PR: https://git.openjdk.java.net/jdk/pull/1825 From sspitsyn at openjdk.java.net Fri Dec 18 03:30:56 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 03:30:56 GMT Subject: RFR: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. Hi Yasumasa, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1800 From ysuenaga at openjdk.java.net Fri Dec 18 04:52:57 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 18 Dec 2020 04:52:57 GMT Subject: Integrated: 8258471: "search codecache" clhsdb command does not work In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 10:27:05 GMT, Yasumasa Suenaga wrote: > `search codecache` command does not work as following: > > hsdb> search codecache 0x7fedbd0aec90 > java.lang.RuntimeException: Unable to deduce type of CodeBlob from address 0x00007fedbc85e810 (expected type nmethod, RuntimeStub, SafepointBlob, DeoptimizationBlob, or ExceptionBlob) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.createCodeBlobWrapper(CodeCache.java:177) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.CodeHeap.iterate(CodeHeap.java:111) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.iterate(CodeCache.java:185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$40.doit(CommandProcessor.java:1535) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2051) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2021) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1901) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483) > > I checked the Object which points 0x7fedbd0aec90, it was `VtableBlob`. It has been introduced in [JDK-8199406](https://bugs.openjdk.java.net/browse/JDK-8199406), but it did not change SA code. > > SA should support `VtableBlob`. This pull request has now been integrated. Changeset: 1e03ca13 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/1e03ca13 Stats: 47 lines in 3 files changed: 46 ins; 0 del; 1 mod 8258471: "search codecache" clhsdb command does not work Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1800 From rrich at openjdk.java.net Fri Dec 18 08:38:03 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 08:38:03 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled Message-ID: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Please review this small enhancement if CDS is disabled. It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms ------------- Commit messages: - Compressed class space should be placed below 32G if heap is above. Changes: https://git.openjdk.java.net/jdk/pull/1815/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1815&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258576 Stats: 36 lines in 2 files changed: 25 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1815.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1815/head:pull/1815 PR: https://git.openjdk.java.net/jdk/pull/1815 From rrich at openjdk.java.net Fri Dec 18 09:42:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 09:42:10 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: > Please review this small enhancement if CDS is disabled. > > It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1815/files - new: https://git.openjdk.java.net/jdk/pull/1815/files/3932ea11..1f7195de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1815&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1815&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1815.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1815/head:pull/1815 PR: https://git.openjdk.java.net/jdk/pull/1815 From lzang at openjdk.java.net Fri Dec 18 09:42:56 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 18 Dec 2020 09:42:56 GMT Subject: RFR: 8258593: remove redundant codes in HeapObjectDumper In-Reply-To: <8NK6nMy1yL5jK04VuUjxrms0n8UdUcEgBOP1REBSUDQ=.f13d7ff9-41c1-418d-b63a-632fdf652b46@github.com> References: <8NK6nMy1yL5jK04VuUjxrms0n8UdUcEgBOP1REBSUDQ=.f13d7ff9-41c1-418d-b63a-632fdf652b46@github.com> Message-ID: On Thu, 17 Dec 2020 15:37:09 GMT, Lois Foltan wrote: >> 8258593: remove redundant codes in HeapObjectDumper > > LGTM. > Lois Dear all, May I ask your help to sponsor this pr? P.S. the failed case on linux x86_32 seems not relate to this change, it is tracked on another issue JDK-8258584. Thanks! -Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/1819 From mdoerr at openjdk.java.net Fri Dec 18 10:10:00 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 18 Dec 2020 10:10:00 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Fri, 18 Dec 2020 09:42:10 GMT, Richard Reingruber wrote: >> Please review this small enhancement if CDS is disabled. >> >> It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. >> >> The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, >> SAP specific tests with fastdebug and release builds on all platforms > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. But the change looks good to me. Thanks for improving it! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Fri Dec 18 10:34:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 10:34:00 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Fri, 18 Dec 2020 09:42:10 GMT, Richard Reingruber wrote: >> Please review this small enhancement if CDS is disabled. >> >> It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. >> >> The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, >> SAP specific tests with fastdebug and release builds on all platforms > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. Hi Richard, small nits, see below. Thanks for fixing. ..Thomas src/hotspot/share/memory/metaspace.cpp line 706: > 704: ReservedSpace rs; > 705: > 706: // If UseCompressedOops=1 and the java heap has been placed in coops-friendly s/has/had src/hotspot/share/memory/metaspace.cpp line 710: > 708: // right above the java heap. > 709: // Otherwise the lower 32G are still free. We try to place ccs at the lowest > 710: // allowed mapping address for efficient encoding of compressed class pointers. `for efficient encoding of compressed class pointers` I'd reformulate this. Both cases are done to efficiently encode narrow class pointers. We place ccs atop of the heap in the hope of piggybacking its efficient allocation. Either I would leave the statement out, since it is somewhat obvious from the context, or I would put it atop of the comment. src/hotspot/share/memory/metaspace.cpp line 711: > 709: // Otherwise the lower 32G are still free. We try to place ccs at the lowest > 710: // allowed mapping address for efficient encoding of compressed class pointers. > 711: address base = (UseCompressedOops && (uint64_t)CompressedOops::base() < OopEncodingHeapMax) ? Should this not somehow take ccs size into consideration? eg size_t gap_above_heap = OopEncodingHeapMax - CompressedOops.end(); if (gap_above_heap >= size) ... ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1815 From rrich at openjdk.java.net Fri Dec 18 12:13:24 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 12:13:24 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Fri, 18 Dec 2020 10:07:26 GMT, Martin Doerr wrote: > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? bool CompressedKlassPointers::is_valid_base(address p) { #ifdef AARCH64 // Below 32G, base must be aligned to 4G. // Above that point, base must be aligned to 32G if (p < (address)(32 * G)) { return is_aligned(p, 4 * G); } return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); #else return true; #endif } On macos `Xlog:os*=debug` prints [0.052s][debug][os ] Attempt to reserve memory at 0x0000000080000000 for 1073741824 bytes failed, errno 2 errno 2 seems to be ENOENT. I don't know what this means. I don't see any mapping at 2G with vmmap. > But the change looks good to me. > Thanks for improving it! Thanks for the review, Martin. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From rrich at openjdk.java.net Fri Dec 18 12:47:27 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 12:47:27 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> On Fri, 18 Dec 2020 10:12:11 GMT, Thomas Stuefe wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. > > src/hotspot/share/memory/metaspace.cpp line 706: > >> 704: ReservedSpace rs; >> 705: >> 706: // If UseCompressedOops=1 and the java heap has been placed in coops-friendly > > s/has/had I'm using [present perfect](https://en.wikipedia.org/wiki/Present_perfect). You suggest to use past perfect (aka [pluperfect](https://en.wikipedia.org/wiki/Pluperfect)). Is that correct so far? If so, then I'd think present perfect is the better fit, isn't it? Note also: the current comment uses the same tense, and it was you who's added it :) > src/hotspot/share/memory/metaspace.cpp line 710: > >> 708: // right above the java heap. >> 709: // Otherwise the lower 32G are still free. We try to place ccs at the lowest >> 710: // allowed mapping address for efficient encoding of compressed class pointers. > > `for efficient encoding of compressed class pointers` I'd reformulate this. Both cases are done to efficiently encode narrow class pointers. We place ccs atop of the heap in the hope of piggybacking its efficient allocation. > > Either I would leave the statement out, since it is somewhat obvious from the context, or I would put it atop of the comment. I'll drop it. > src/hotspot/share/memory/metaspace.cpp line 711: > >> 709: // Otherwise the lower 32G are still free. We try to place ccs at the lowest >> 710: // allowed mapping address for efficient encoding of compressed class pointers. >> 711: address base = (UseCompressedOops && (uint64_t)CompressedOops::base() < OopEncodingHeapMax) ? > > Should this not somehow take ccs size into consideration? > eg > size_t gap_above_heap = OopEncodingHeapMax - CompressedOops.end(); > if (gap_above_heap >= size) ... Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From mdoerr at openjdk.java.net Fri Dec 18 13:09:23 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 18 Dec 2020 13:09:23 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Fri, 18 Dec 2020 12:10:23 GMT, Richard Reingruber wrote: > HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? I guess we could get rid of it, but we'd need to ask an aarch64 expert. I think we can also leave it as it is for now. Thanks for figuring this out. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Fri Dec 18 14:29:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 14:29:27 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> Message-ID: On Fri, 18 Dec 2020 12:44:28 GMT, Richard Reingruber wrote: > Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? It should not be beyond 32G if heap was places below 32G, no? What I meant was: if the heap end is below 32g, and there is enough space between heap end and narrow klass pointer encoding range, place the ccs at heap end, otherwise try a low address. But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. Existence of the heap only matters insofar as it is a maybe large mapping which maybe got placed into the address range we covet. But other mappings are large too, and live in that same range. So why care for the heap in particular. It would make the coding way simpler and increase chances of placing ccs if we were to just start at a low address, attempt to attach at regular intervals - while observing platform restrictions (see CompressedOops::is_valid_base()) - until the 32g ceiling is reached. We do not really need to care for heap placement. If heap happens to live below 32G too - irregardless of UseCompressedOops - then some of our mmaps would fail. But that is fine. For example, if we were to start at, say, 4g, and attempt to attach at 8, 12, 16...28g, I think this would work just fine on all platforms. It would not take much time either. mmap is fast if it fails. Plus, this is a rare corner case anyway. And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. > > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. > > HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? > > ``` > bool CompressedKlassPointers::is_valid_base(address p) { > #ifdef AARCH64 > // Below 32G, base must be aligned to 4G. > // Above that point, base must be aligned to 32G > if (p < (address)(32 * G)) { > return is_aligned(p, 4 * G); > } > return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); > #else > return true; > #endif > } > ``` > No, this coding is correct. See comment above the function. This coding returns true if the given value is usable as a _narrow klass base_. On aarch64, 0 is valid, if its not 0, it has to be 4G aligned (below 32G), 4G<<3 above. 2G is not a correct base. 2G would be valid as start of ccs though. But that distinction would have to be clearly coded out, atm its not. See metaspace.cpp:717 and :739. But I am not sure if its worth the complexity. For more details, please see: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html , also, the review thread for JDK-8243392. Please do not change this coding in CompressedClassPointers without talking with the aarch64 devs, since this was done with them together as part of JDK-8243392. Should you change that, could you please do it in a seperate RFE? One problem with this coding is since this is not really used much (CDS is enabled 99% of the time) it is not that well covered by tests. I run into that problem repeatedly in the past. > On macos `Xlog:os*=debug` prints > > ``` > [0.052s][debug][os ] Attempt to reserve memory at 0x0000000080000000 for 1073741824 bytes failed, errno 2 > ``` > > errno 2 seems to be ENOENT. I don't know what this means. I don't see any mapping at 2G with vmmap. errno may be stale. It is printed miles away from the failing mmap call. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Fri Dec 18 14:43:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 14:43:27 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> Message-ID: <0iQIWJu6FH2Pgpmty9VcJsv43MKFZIKxfqv-HMl6x8A=.c7fc0856-6c1b-4c67-94ed-6cd9ea0c184a@github.com> On Fri, 18 Dec 2020 14:26:56 GMT, Thomas Stuefe wrote: >> Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? > >> Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? > > It should not be beyond 32G if heap was places below 32G, no? > > What I meant was: if the heap end is below 32g, and there is enough space between heap end and narrow klass pointer encoding range, place the ccs at heap end, otherwise try a low address. > > But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. Existence of the heap only matters insofar as it is a maybe large mapping which maybe got placed into the address range we covet. But other mappings are large too, and live in that same range. So why care for the heap in particular. > > It would make the coding way simpler and increase chances of placing ccs if we were to just start at a low address, attempt to attach at regular intervals - while observing platform restrictions (see CompressedOops::is_valid_base()) - until the 32g ceiling is reached. We do not really need to care for heap placement. If heap happens to live below 32G too - irregardless of UseCompressedOops - then some of our mmaps would fail. But that is fine. > > For example, if we were to start at, say, 4g, and attempt to attach at 8, 12, 16...28g, I think this would work just fine on all platforms. It would not take much time either. mmap is fast if it fails. Plus, this is a rare corner case anyway. > > And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. > >> > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. >> >> HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? >> >> ``` >> bool CompressedKlassPointers::is_valid_base(address p) { >> #ifdef AARCH64 >> // Below 32G, base must be aligned to 4G. >> // Above that point, base must be aligned to 32G >> if (p < (address)(32 * G)) { >> return is_aligned(p, 4 * G); >> } >> return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); >> #else >> return true; >> #endif >> } >> ``` >> > > No, this coding is correct. See comment above the function. This coding returns true if the given value is usable as a _narrow klass base_. On aarch64, 0 is valid, if its not 0, it has to be 4G aligned (below 32G), 4G<<3 above. 2G is not a correct base. 2G would be valid as start of ccs though. But that distinction would have to be clearly coded out, atm its not. See metaspace.cpp:717 and :739. But I am not sure if its worth the complexity. > > For more details, please see: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html , also, the review thread for JDK-8243392. > > Please do not change this coding in CompressedClassPointers without talking with the aarch64 devs, since this was done with them together as part of JDK-8243392. Should you change that, could you please do it in a seperate RFE? > > One problem with this coding is since this is not really used much (CDS is enabled 99% of the time) it is not that well covered by tests. I run into that problem repeatedly in the past. > >> On macos `Xlog:os*=debug` prints >> >> ``` >> [0.052s][debug][os ] Attempt to reserve memory at 0x0000000080000000 for 1073741824 bytes failed, errno 2 >> ``` >> >> errno 2 seems to be ENOENT. I don't know what this means. I don't see any mapping at 2G with vmmap. > > errno may be stale. It is printed miles away from the failing mmap call. One other aspect to check, if ccs is placed below the heap, is whether it gets placed in the way of the sbrk. Important for platforms which implement malloc via sbrk, because you could get malloc fails later. It is the case for AIX and Solaris at least (the latter matters when downporting). For AIX, I added safety coding right into os::reserve_memory. It may also be an issue on MacOS, that should be tested. I believe glibc is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From rrich at openjdk.java.net Fri Dec 18 15:49:56 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 15:49:56 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: <0iQIWJu6FH2Pgpmty9VcJsv43MKFZIKxfqv-HMl6x8A=.c7fc0856-6c1b-4c67-94ed-6cd9ea0c184a@github.com> References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> <0iQIWJu6FH2Pgpmty9VcJsv43MKFZIKxfqv-HMl6x8A=.c7fc0856-6c1b-4c67-94ed-6cd9ea0c184a@github.com> Message-ID: On Fri, 18 Dec 2020 14:40:39 GMT, Thomas Stuefe wrote: >>> Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? >> >> It should not be beyond 32G if heap was places below 32G, no? >> >> What I meant was: if the heap end is below 32g, and there is enough space between heap end and narrow klass pointer encoding range, place the ccs at heap end, otherwise try a low address. >> >> But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. Existence of the heap only matters insofar as it is a maybe large mapping which maybe got placed into the address range we covet. But other mappings are large too, and live in that same range. So why care for the heap in particular. >> >> It would make the coding way simpler and increase chances of placing ccs if we were to just start at a low address, attempt to attach at regular intervals - while observing platform restrictions (see CompressedOops::is_valid_base()) - until the 32g ceiling is reached. We do not really need to care for heap placement. If heap happens to live below 32G too - irregardless of UseCompressedOops - then some of our mmaps would fail. But that is fine. >> >> For example, if we were to start at, say, 4g, and attempt to attach at 8, 12, 16...28g, I think this would work just fine on all platforms. It would not take much time either. mmap is fast if it fails. Plus, this is a rare corner case anyway. >> >> And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. >> >>> > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. >>> >>> HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? >>> >>> ``` >>> bool CompressedKlassPointers::is_valid_base(address p) { >>> #ifdef AARCH64 >>> // Below 32G, base must be aligned to 4G. >>> // Above that point, base must be aligned to 32G >>> if (p < (address)(32 * G)) { >>> return is_aligned(p, 4 * G); >>> } >>> return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); >>> #else >>> return true; >>> #endif >>> } >>> ``` >>> >> >> No, this coding is correct. See comment above the function. This coding returns true if the given value is usable as a _narrow klass base_. On aarch64, 0 is valid, if its not 0, it has to be 4G aligned (below 32G), 4G<<3 above. 2G is not a correct base. 2G would be valid as start of ccs though. But that distinction would have to be clearly coded out, atm its not. See metaspace.cpp:717 and :739. But I am not sure if its worth the complexity. >> >> For more details, please see: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html , also, the review thread for JDK-8243392. >> >> Please do not change this coding in CompressedClassPointers without talking with the aarch64 devs, since this was done with them together as part of JDK-8243392. Should you change that, could you please do it in a seperate RFE? >> >> One problem with this coding is since this is not really used much (CDS is enabled 99% of the time) it is not that well covered by tests. I run into that problem repeatedly in the past. >> >>> On macos `Xlog:os*=debug` prints >>> >>> ``` >>> [0.052s][debug][os ] Attempt to reserve memory at 0x0000000080000000 for 1073741824 bytes failed, errno 2 >>> ``` >>> >>> errno 2 seems to be ENOENT. I don't know what this means. I don't see any mapping at 2G with vmmap. >> >> errno may be stale. It is printed miles away from the failing mmap call. > > One other aspect to check, if ccs is placed below the heap, is whether it gets placed in the way of the sbrk. Important for platforms which implement malloc via sbrk, because you could get malloc fails later. It is the case for AIX and Solaris at least (the latter matters when downporting). For AIX, I added safety coding right into os::reserve_memory. It may also be an issue on MacOS, that should be tested. I believe glibc is fine. > > > > Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? > > It should not be beyond 32G if heap was places below 32G, no? > Ok, I see, but this is not the point of the enhancement. The point here is to make use of the lower 32G if the heap is above that limit. And I'd like to keep that scope. I'm planning to downport the small change to 11u where CDS is off by default. Of course you can further optimize this in a follow-up. > But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. That observation is correct. I wanted to eliminate the dependency but unfortunately I haven't found something in CollectedHeap that takes the noaccess prefix required for the not-zerobased coops heap into account (the noaccess prefix is a protected page used for implicit null checks). CompressedOops::base() does. > And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. I think the naming is incidental. AFAIK the intend is not to use the address space below HeapBaseMinAddress. > > > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. > > > > > > HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? > > ``` > > bool CompressedKlassPointers::is_valid_base(address p) { > > #ifdef AARCH64 > > // Below 32G, base must be aligned to 4G. > > // Above that point, base must be aligned to 32G > > if (p < (address)(32 * G)) { > > return is_aligned(p, 4 * G); > > } > > return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); > > #else > > return true; > > #endif > > } > > ``` > > No, this coding is correct. See comment above the function. The comment says // Given an address p, return true if p can be used as an encoding base. // (Some platforms have restrictions of what constitutes a valid base address). But the parameter passed is not the encoding base. It is the desired beginning of ccs. If ccs is mapped at 2G then the encoding base is 0 (actually it is 0 if the ccs end is <= KlassEncodingMetaspaceMax, see CompressedKlassPointers::initialize). So either the function or its users are not correct. In other words: mapping ccs at 2G would result in a zerobased ccs. I'd be extremely surprised if 0x0 as encoding base is actually invalid on aarch64. IMHO opinion it is a bug that it is not allowed to map ccs at 2g on aarch64. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From dcubed at openjdk.java.net Fri Dec 18 17:19:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Dec 2020 17:19:05 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles Message-ID: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> While working on JDK-8231627, I discovered there were issues with nested ThreadsListHandles. I added a new test to verify how ThreadsListHandles and nested ThreadsListHandles are supposed to work. I found two bugs: 1) A failure to restore the expected _threads_hazard_ptr when a nested ThreadsListHandle is destroyed. 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested ThreadsListHandle is destroyed. The second failure mode is what tripped up my fix for JDK-8231627 so that bug fix depends on this bug fix. Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). ------------- Commit messages: - 8258284 Changes: https://git.openjdk.java.net/jdk/pull/1844/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1844&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258284 Stats: 720 lines in 4 files changed: 705 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1844/head:pull/1844 PR: https://git.openjdk.java.net/jdk/pull/1844 From dcubed at openjdk.java.net Fri Dec 18 17:19:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Dec 2020 17:19:05 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles In-Reply-To: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: On Fri, 18 Dec 2020 17:07:27 GMT, Daniel D. Daugherty wrote: > While working on JDK-8231627, I discovered there were issues with nested > ThreadsListHandles. I added a new test to verify how ThreadsListHandles and > nested ThreadsListHandles are supposed to work. I found two bugs: > > 1) A failure to restore the expected _threads_hazard_ptr when a nested > ThreadsListHandle is destroyed. > > 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested > ThreadsListHandle is destroyed. > > The second failure mode is what tripped up my fix for JDK-8231627 so that > bug fix depends on this bug fix. > > Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). @dholmes-ora, @fisk and @robehn - You three are the usual folks that review Thread-SMR stuff. @fisk - this should be of particular interest to you since I'm tweaking your changes to the nested ThreadsListHandle code. ------------- PR: https://git.openjdk.java.net/jdk/pull/1844 From stuefe at openjdk.java.net Fri Dec 18 17:25:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 17:25:59 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> <0iQIWJu6FH2Pgpmty9VcJsv43MKFZIKxfqv-HMl6x8A=.c7fc0856-6c1b-4c67-94ed-6cd9ea0c184a@github.com> Message-ID: <0noYz315kkeJ4RNcrZ-W3yZSYPaQTeqLT9GqQMAB-6o=.ae00f182-ec98-4b7c-84e0-6fc494f2cb35@github.com> On Fri, 18 Dec 2020 15:47:12 GMT, Richard Reingruber wrote: > > > Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? > > > > > > It should not be beyond 32G if heap was places below 32G, no? > > Ok, I see, but this is not the point of the enhancement. The point here is to > make use of the lower 32G if the heap is above that limit. > > And I'd like to keep that scope. I'm planning to downport the small change to 11u > where CDS is off by default. Your proposal increases complexity for the benefit of a rather small corner case; my proposal (disregarding heap specifics completely and just attempting ladder-attaching in the 32g range) would decrease complexity while improving placement chances below 32g a lot more. Are there any reasons why this would not work? If not, why not choose the better approach? If its just about backporting, I do not think that should dictate what solution we choose. Rather implement the small solution in 11u directly then. I also do not think there is any time pressure here. So we can afford us the luxury to do things right instead of rushing it. > > Of course you can further optimize this in a follow-up. > > > But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. > > That observation is correct. I wanted to eliminate the dependency but > unfortunately I haven't found something in CollectedHeap that takes the noaccess > prefix required for the not-zerobased coops heap into account (the noaccess > prefix is a protected page used for implicit null > checks). CompressedOops::base() does. > > > And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. > > I think the naming is incidental. AFAIK the intend is not to use the address space below HeapBaseMinAddress. > > > > > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. > > > > > > > > > HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? > > > ``` > > > bool CompressedKlassPointers::is_valid_base(address p) { > > > #ifdef AARCH64 > > > // Below 32G, base must be aligned to 4G. > > > // Above that point, base must be aligned to 32G > > > if (p < (address)(32 * G)) { > > > return is_aligned(p, 4 * G); > > > } > > > return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); > > > #else > > > return true; > > > #endif > > > } > > > ``` > > > > > > No, this coding is correct. See comment above the function. > > The comment says > > ``` > // Given an address p, return true if p can be used as an encoding base. > // (Some platforms have restrictions of what constitutes a valid base address). > ``` > > But the parameter passed is not the encoding base. It is the desired beginning > of ccs. If ccs is mapped at 2G then the encoding base is 0 (actually it is 0 if > the ccs end is <= KlassEncodingMetaspaceMax, see > CompressedKlassPointers::initialize). So either the function or its users are > not correct. > Is that not what I wrote? I quote myself: >> This coding returns true if the given value is usable as a _narrow klass base_. >> >> 2G would be valid as start of ccs though. But that distinction would have to be clearly coded out, atm its not. See metaspace.cpp:717 and :739. But I am not sure if its worth the complexity. So the function is correct. The usage is incorrect. > In other words: mapping ccs at 2G would result in a zerobased ccs. I'd be extremely > surprised if 0x0 as encoding base is actually invalid on aarch64. IMHO opinion > it is a bug that it is not allowed to map ccs at 2g on aarch64. Sure. This is my error, slipped in with the CDS remodelling. Feel free to file a bug report about this and put it on my name. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From ccheung at openjdk.java.net Fri Dec 18 17:32:54 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 18 Dec 2020 17:32:54 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory In-Reply-To: References: Message-ID: <5tA0taAmNeTWctBmGdvaD-yZCGmNFB8mCksbDtEWXoE=.6585e35a-64ac-4188-a5a7-11f05afbc47d@github.com> On Thu, 17 Dec 2020 19:05:00 GMT, Yumin Qi wrote: > Hi, Please review > This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). > This step remove the function split_reserved_memory which no longer be called after first step. > > Tests: tier1-4 > > Thanks > Yumin Looks good other than a minor cleanup. src/hotspot/share/memory/virtualspace.hpp line 83: > 81: > 82: // These simply call the above using the default alignment. > 83: inline ReservedSpace first_part(size_t partition_size/*, bool split = false*/); Forgot to remove the comment code `/*, bool split = false*/`? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1825 From minqi at openjdk.java.net Fri Dec 18 17:37:54 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Dec 2020 17:37:54 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory In-Reply-To: <5tA0taAmNeTWctBmGdvaD-yZCGmNFB8mCksbDtEWXoE=.6585e35a-64ac-4188-a5a7-11f05afbc47d@github.com> References: <5tA0taAmNeTWctBmGdvaD-yZCGmNFB8mCksbDtEWXoE=.6585e35a-64ac-4188-a5a7-11f05afbc47d@github.com> Message-ID: On Fri, 18 Dec 2020 17:28:22 GMT, Calvin Cheung wrote: >> Hi, Please review >> This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). >> This step remove the function split_reserved_memory which no longer be called after first step. >> >> Tests: tier1-4 >> >> Thanks >> Yumin > > src/hotspot/share/memory/virtualspace.hpp line 83: > >> 81: >> 82: // These simply call the above using the default alignment. >> 83: inline ReservedSpace first_part(size_t partition_size/*, bool split = false*/); > > Forgot to remove the comment code `/*, bool split = false*/`? Yes, thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1825 From eosterlund at openjdk.java.net Fri Dec 18 17:43:54 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 18 Dec 2020 17:43:54 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles In-Reply-To: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: On Fri, 18 Dec 2020 17:07:27 GMT, Daniel D. Daugherty wrote: > While working on JDK-8231627, I discovered there were issues with nested > ThreadsListHandles. I added a new test to verify how ThreadsListHandles and > nested ThreadsListHandles are supposed to work. I found two bugs: > > 1) A failure to restore the expected _threads_hazard_ptr when a nested > ThreadsListHandle is destroyed. > > 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested > ThreadsListHandle is destroyed. > > The second failure mode is what tripped up my fix for JDK-8231627 so that > bug fix depends on this bug fix. > > Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). One small nit about using Atomic::store(). Otherwise it looks good. Great that you found this and added a test so it won't bite us again. src/hotspot/share/runtime/threadSMR.cpp line 476: > 474: // Clear the hazard ptr so we can go through the fast path below and > 475: // acquire a nested stable ThreadsList. > 476: _thread->_threads_hazard_ptr = NULL; Should be Atomic::store() ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1844 From minqi at openjdk.java.net Fri Dec 18 17:45:14 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Dec 2020 17:45:14 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory [v2] In-Reply-To: References: Message-ID: > Hi, Please review > This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). > This step remove the function split_reserved_memory which no longer be called after first step. > > Tests: tier1-4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove unused comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1825/files - new: https://git.openjdk.java.net/jdk/pull/1825/files/4318c9a3..a7c49002 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1825&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1825&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1825.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1825/head:pull/1825 PR: https://git.openjdk.java.net/jdk/pull/1825 From dcubed at openjdk.java.net Fri Dec 18 17:52:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Dec 2020 17:52:56 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles In-Reply-To: References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: On Fri, 18 Dec 2020 17:40:22 GMT, Erik ?sterlund wrote: >> While working on JDK-8231627, I discovered there were issues with nested >> ThreadsListHandles. I added a new test to verify how ThreadsListHandles and >> nested ThreadsListHandles are supposed to work. I found two bugs: >> >> 1) A failure to restore the expected _threads_hazard_ptr when a nested >> ThreadsListHandle is destroyed. >> >> 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested >> ThreadsListHandle is destroyed. >> >> The second failure mode is what tripped up my fix for JDK-8231627 so that >> bug fix depends on this bug fix. >> >> Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). > > src/hotspot/share/runtime/threadSMR.cpp line 476: > >> 474: // Clear the hazard ptr so we can go through the fast path below and >> 475: // acquire a nested stable ThreadsList. >> 476: _thread->_threads_hazard_ptr = NULL; > > Should be Atomic::store() That's a bug in the baseline also, but I can fix it since I'm already touching that line. I also noticed that we weren't really consistent about using atomic operations with the _threads_hazard_ptr field and we don't always use the (mis-named) get_threads_hazard_ptr(). I plan to make another cleanup pass with a different bug ID for those. ------------- PR: https://git.openjdk.java.net/jdk/pull/1844 From dcubed at openjdk.java.net Fri Dec 18 18:09:13 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Dec 2020 18:09:13 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles [v2] In-Reply-To: References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: <-NthEDQA4m-QPuu-8IzN9j5Xolh6rRxA77mmAXfDIeQ=.e744379d-fc01-4a6c-bb32-5f1081fbc2dc@github.com> On Fri, 18 Dec 2020 17:41:15 GMT, Erik ?sterlund wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolve @fisk CR about using Atomic::store(). > > One small nit about using Atomic::store(). Otherwise it looks good. Great that you found this and added a test so it won't bite us again. @fisk - Thanks for the fast review. Fixed in the incremental that I just pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1844 From dcubed at openjdk.java.net Fri Dec 18 18:09:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Dec 2020 18:09:12 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles [v2] In-Reply-To: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: > While working on JDK-8231627, I discovered there were issues with nested > ThreadsListHandles. I added a new test to verify how ThreadsListHandles and > nested ThreadsListHandles are supposed to work. I found two bugs: > > 1) A failure to restore the expected _threads_hazard_ptr when a nested > ThreadsListHandle is destroyed. > > 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested > ThreadsListHandle is destroyed. > > The second failure mode is what tripped up my fix for JDK-8231627 so that > bug fix depends on this bug fix. > > Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Resolve @fisk CR about using Atomic::store(). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1844/files - new: https://git.openjdk.java.net/jdk/pull/1844/files/4f1594df..95d77ca1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1844&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1844&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1844/head:pull/1844 PR: https://git.openjdk.java.net/jdk/pull/1844 From iklam at openjdk.java.net Fri Dec 18 18:42:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 18 Dec 2020 18:42:56 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory [v2] In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 17:45:14 GMT, Yumin Qi wrote: >> Hi, Please review >> This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). >> This step remove the function split_reserved_memory which no longer be called after first step. >> >> Tests: tier1-4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused comment LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1825 From minqi at openjdk.java.net Fri Dec 18 18:53:54 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Dec 2020 18:53:54 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory [v2] In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 18:39:42 GMT, Ioi Lam wrote: > LGTM Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1825 From minqi at openjdk.java.net Fri Dec 18 20:26:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Dec 2020 20:26:56 GMT Subject: Integrated: 8256213: Remove os::split_reserved_memory In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 19:05:00 GMT, Yumin Qi wrote: > Hi, Please review > This is the second step for removing problematic os::split_reserved_memory on Windows. The first step has been accomplished under bug 8255917 (https://bugs.openjdk.java.net/browse/JDK-8255917). > This step remove the function split_reserved_memory which no longer be called after first step. > > Tests: tier1-4 > > Thanks > Yumin This pull request has now been integrated. Changeset: 06c24e14 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/06c24e14 Stats: 70 lines in 6 files changed: 0 ins; 63 del; 7 mod 8256213: Remove os::split_reserved_memory Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1825 From stuefe at openjdk.java.net Sat Dec 19 06:35:53 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 19 Dec 2020 06:35:53 GMT Subject: RFR: 8256213: Remove os::split_reserved_memory [v2] In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 18:51:15 GMT, Yumin Qi wrote: >> LGTM > >> LGTM > > Thanks for review! Nice to see this gone ! ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1825 From aph at openjdk.java.net Sat Dec 19 11:08:59 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 19 Dec 2020 11:08:59 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> Message-ID: On Fri, 18 Dec 2020 12:43:43 GMT, Richard Reingruber wrote: > I'm using [present perfect](https://en.wikipedia.org/wiki/Present_perfect). I agree: present perfect is correct here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Sat Dec 19 18:27:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 19 Dec 2020 18:27:00 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Fri, 18 Dec 2020 09:42:10 GMT, Richard Reingruber wrote: >> Please review this small enhancement if CDS is disabled. >> >> It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. >> >> The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, >> SAP specific tests with fastdebug and release builds on all platforms > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. Hi Richard, I don't want to block this. Feel free to commit this. Since you want to keep the change minimal to aid backporting, I would refrain from changing the logic which initiatializes CompressedOops. Instead, I would just use 4G instead of heapBaseMinAddress on aarch64. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Sun Dec 20 10:58:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 20 Dec 2020 10:58:54 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> <9H01i-lWKXLccCVhwd3mBdbkpAt_qvHHzK2ow5QC8QE=.01c4a712-d4ef-4177-9a6a-612628452a6e@github.com> <0iQIWJu6FH2Pgpmty9VcJsv43MKFZIKxfqv-HMl6x8A=.c7fc0856-6c1b-4c67-94ed-6cd9ea0c184a@github.com> Message-ID: <2yPoZiirB8Wv-qD1472mqwzl1yAt_JIFzjkmck6tPAQ=.4b4cdbc3-476b-4721-bea0-263d834dca6e@github.com> On Fri, 18 Dec 2020 15:47:12 GMT, Richard Reingruber wrote: >> One other aspect to check, if ccs is placed below the heap, is whether it gets placed in the way of the sbrk. Important for platforms which implement malloc via sbrk, because you could get malloc fails later. It is the case for AIX and Solaris at least (the latter matters when downporting). For AIX, I added safety coding right into os::reserve_memory. It may also be an issue on MacOS, that should be tested. I believe glibc is fine. > >> >> >> > Hm, I don't understand that one. OopEncodingHeapMax is normally 32G. CompressedOops.end() is the end of the coops heap; probably way higher than 32G. So you will get an underflow in the substraction, won't you? >> >> It should not be beyond 32G if heap was places below 32G, no? >> > > Ok, I see, but this is not the point of the enhancement. The point here is to > make use of the lower 32G if the heap is above that limit. > > And I'd like to keep that scope. I'm planning to downport the small change to 11u > where CDS is off by default. > > Of course you can further optimize this in a follow-up. > >> But the more I look at this coding the more I think this should not depend on heap and UseCompressedOops at all. UseCompressedOops does not really matter. > > That observation is correct. I wanted to eliminate the dependency but > unfortunately I haven't found something in CollectedHeap that takes the noaccess > prefix required for the not-zerobased coops heap into account (the noaccess > prefix is a protected page used for implicit null > checks). CompressedOops::base() does. > >> And note that the low address does not have to be HeapBaseMinAddress either. ccs can live anywhere. The dependence on HeapBaseMinAddress is incidental. > > I think the naming is incidental. AFAIK the intend is not to use the address space below HeapBaseMinAddress. > >> > > It would be interesting to know why aarch64 and OSX don't use shift 0 in the new test case. >> > >> > >> > HeapBaseMinAddress seems to be 2G on all platforms. On AARCH64 2G is considered invalid because it is not 4G aligned. I must admit that I don't understand this. Below 32G the CCS will be zerobased. There is no need to load the base address efficiently into a register. I think that part could be removed, don't you think that too? >> > ``` >> > bool CompressedKlassPointers::is_valid_base(address p) { >> > #ifdef AARCH64 >> > // Below 32G, base must be aligned to 4G. >> > // Above that point, base must be aligned to 32G >> > if (p < (address)(32 * G)) { >> > return is_aligned(p, 4 * G); >> > } >> > return is_aligned(p, (4 << LogKlassAlignmentInBytes) * G); >> > #else >> > return true; >> > #endif >> > } >> > ``` >> >> No, this coding is correct. See comment above the function. > > The comment says > > // Given an address p, return true if p can be used as an encoding base. > // (Some platforms have restrictions of what constitutes a valid base address). > > But the parameter passed is not the encoding base. It is the desired beginning > of ccs. If ccs is mapped at 2G then the encoding base is 0 (actually it is 0 if > the ccs end is <= KlassEncodingMetaspaceMax, see > CompressedKlassPointers::initialize). So either the function or its users are > not correct. > > In other words: mapping ccs at 2G would result in a zerobased ccs. I'd be extremely > surprised if 0x0 as encoding base is actually invalid on aarch64. IMHO opinion > it is a bug that it is not allowed to map ccs at 2g on aarch64. > One other aspect to check, if ccs is placed below the heap, is whether it gets placed in the way of the sbrk. Important for platforms which implement malloc via sbrk, because you could get malloc fails later. It is the case for AIX and Solaris at least (the latter matters when downporting). For AIX, I added safety coding right into os::reserve_memory. It may also be an issue on MacOS, that should be tested. I believe glibc is fine. Thinking this through, I believe we are covered here - or at least this patch won't introduce any problems we don't already have - since we already have code paths attaching at HeapBaseMinAddress. It might be good to file a future RFE to extend the AIX workaround (which prevents attaching to a configurable safety zone above brk) to all platforms. Just on the off-chance that someone (libc or third party code) uses sbrk() for memory allocation. But that is a separate issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Sun Dec 20 12:10:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 20 Dec 2020 12:10:56 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Sat, 19 Dec 2020 18:23:54 GMT, Thomas Stuefe wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> In largeHeapAbove32GTest we have a klass shift of 3 on OSX too. > > Hi Richard, > > I don't want to block this. Feel free to commit this. Since you want to keep the change minimal to aid backporting, I would refrain from changing the logic which initiatializes CompressedOops. Instead, I would just use 4G instead of heapBaseMinAddress on aarch64. > > Cheers, Thomas BTW, mid-term I'd like to implement this: https://bugs.openjdk.java.net/browse/JDK-8258743. I already have a promising prototype for Windows, which was kind of a by product of the recent CDS reservation changes. What do you think, does that make sense to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From stuefe at openjdk.java.net Mon Dec 21 05:36:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 21 Dec 2020 05:36:02 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers Message-ID: This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. Before: Signal Handlers: SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO Now: Signal Handlers: SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. It also introduces gtests for that function. I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1839/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1839&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258606 Stats: 177 lines in 4 files changed: 148 ins; 25 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1839/head:pull/1839 PR: https://git.openjdk.java.net/jdk/pull/1839 From rrich at openjdk.java.net Mon Dec 21 09:12:12 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 21 Dec 2020 09:12:12 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v3] In-Reply-To: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: > Please review this small enhancement if CDS is disabled. > > It tries to get a zerobased compressed class space if we have a not-zerobased compressed oops heap, i.e. the heap is above 32g. In this case there is a good chance to locate CCS below 32g. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Feedback Thomas. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1815/files - new: https://git.openjdk.java.net/jdk/pull/1815/files/1f7195de..6eecfed2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1815&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1815&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1815.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1815/head:pull/1815 PR: https://git.openjdk.java.net/jdk/pull/1815 From dholmes at openjdk.java.net Mon Dec 21 09:15:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Dec 2020 09:15:56 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 10:10:13 GMT, Thomas Stuefe wrote: > This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. > > Before: > Signal Handlers: > SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > Signal Handlers: > SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none > > The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. > > It also introduces gtests for that function. > > I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. A minor comment, but otherwise this seems quite reasonable. Thanks, David src/hotspot/os/posix/signals_posix.cpp line 1352: > 1350: LINUX_ONLY(sa.sa_flags &= SA_RESTORER_FLAG_MASK;) > 1351: > 1352: st->print("%10s: ", os::exception_name(sig, buf, buflen)); Where does the 10 come from? Why do we need to limit it? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1839 From rrich at openjdk.java.net Mon Dec 21 10:25:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 21 Dec 2020 10:25:55 GMT Subject: RFR: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled [v2] In-Reply-To: References: <6nmb8G7P0LGVJqWQLCoLuQTuWVo7k26347GQulZTuTA=.113cb1d4-13b3-411f-ae81-6f1aec5b0631@github.com> Message-ID: On Sun, 20 Dec 2020 12:08:01 GMT, Thomas Stuefe wrote: >> Hi Richard, >> >> I don't want to block this. Feel free to commit this. Since you want to keep the change minimal to aid backporting, I would refrain from changing the logic which initiatializes CompressedOops. Instead, I would just use 4G instead of heapBaseMinAddress on aarch64. >> >> Cheers, Thomas > > BTW, mid-term I'd like to implement this: https://bugs.openjdk.java.net/browse/JDK-8258743. I already have a promising prototype for Windows, which was kind of a by product of the recent CDS reservation changes. What do you think, does that make sense to you? Hi Thomas, > BTW, mid-term I'd like to implement this: > https://bugs.openjdk.java.net/browse/JDK-8258743. I already have a promising > prototype for Windows, which was kind of a by product of the recent CDS > reservation changes. What do you think, does that make sense to you? Well, I would think that in most cases the trial and error method will succeed at first try. This doesn't leave much room for enhancement. Building a vmmap looks like more effort too me. Just my .02? > I don't want to block this. Feel free to commit this. Since you want to keep > the change minimal to aid backporting, Ok. There may be room for further enhancements after this. Also I reckon it could be better to place ccs just below 4G instead of placing it at 2G (HeapBaseMinAddress) for less fragmentation of the 32bit addressable range if possible. I'm not sure how important this would be though. > I would refrain from changing the logic which initiatializes > CompressedOops. Instead, I would just use 4G instead of heapBaseMinAddress on > aarch64. Hm, I think you meant CompressedKlassPointers and the issue related to CompressedKlassPointers::is_valid_base(), right? I won't do changes for that. I've created https://bugs.openjdk.java.net/browse/JDK-8258756 for tracking. Thanks for the review, Richard. PS: I won't integrate until next year since I'll be off for holidays now ------------- PR: https://git.openjdk.java.net/jdk/pull/1815 From dcubed at openjdk.java.net Mon Dec 21 22:16:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 21 Dec 2020 22:16:07 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Message-ID: ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. ------------- Commit messages: - 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Changes: https://git.openjdk.java.net/jdk16/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258802 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/57/head:pull/57 PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Mon Dec 21 22:16:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 21 Dec 2020 22:16:07 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: <4V17EMVLkjvzEvxTXE2m034GAsOZW36cfo9n8WxAJPs=.fa94c4ba-734a-4027-827c-d2a664dbad2e@github.com> On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Links to the JDK16 CI failures for each of the three tests are in the bug report. ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From amenkov at openjdk.java.net Mon Dec 21 22:47:54 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 21 Dec 2020 22:47:54 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From cjplummer at openjdk.java.net Mon Dec 21 23:29:56 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 21 Dec 2020 23:29:56 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From kbarrett at openjdk.java.net Tue Dec 22 05:10:08 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 22 Dec 2020 05:10:08 GMT Subject: RFR: 8256814: WeakProcessorPhases may be redundant Message-ID: Please review this change which eliminates the WeakProcessorPhase class. The OopStorageSet class is changed to provide scoped enums for the different categories: StrongId, WeakId, and Id (for the union of strong and weak). An accessor is provided for obtaining the storage corresponding to a category value. Various other enumerator ranges, array sizes and indices, and iterations are derived directly from the corresponding OopStorageSet category's enum range. Iteration over a category of enumerators can be done via EnumIterator. The iteration over storage objects makes use of that enum iteration, rather than having a bespoke implementation. Some use-cases need iteration of the enumerators, with storage lookup from the enumerator; other use-cases just need the storage objects. Testing: mach5 tier1-6 Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC ------------- Commit messages: - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256814 Stats: 1034 lines in 25 files changed: 400 ins; 465 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862 From rehn at openjdk.java.net Tue Dec 22 09:35:57 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Dec 2020 09:35:57 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles [v2] In-Reply-To: References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: On Fri, 18 Dec 2020 18:09:12 GMT, Daniel D. Daugherty wrote: >> While working on JDK-8231627, I discovered there were issues with nested >> ThreadsListHandles. I added a new test to verify how ThreadsListHandles and >> nested ThreadsListHandles are supposed to work. I found two bugs: >> >> 1) A failure to restore the expected _threads_hazard_ptr when a nested >> ThreadsListHandle is destroyed. >> >> 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested >> ThreadsListHandle is destroyed. >> >> The second failure mode is what tripped up my fix for JDK-8231627 so that >> bug fix depends on this bug fix. >> >> Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Resolve @fisk CR about using Atomic::store(). Thanks ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1844 From coleenp at openjdk.java.net Tue Dec 22 13:19:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Dec 2020 13:19:55 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers In-Reply-To: References: Message-ID: On Fri, 18 Dec 2020 10:10:13 GMT, Thomas Stuefe wrote: > This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. > > Before: > Signal Handlers: > SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > Signal Handlers: > SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none > > The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. > > It also introduces gtests for that function. > > I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. Looks good. src/hotspot/share/runtime/os.cpp line 906: > 904: } > 905: int offset = 0; > 906: const bool have_function_name = dll_address_to_function_name(addr, p, buflen, So this function includes the arguments in the string that it returns? The arguments make the output long and don't add anything helpful in my opinion, but it's not really worth having the code to strip them out. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1839 From dcubed at openjdk.java.net Tue Dec 22 13:45:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 13:45:58 GMT Subject: [jdk16] Integrated: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:09:33 GMT, Daniel D. Daugherty wrote: > ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. This pull request has now been integrated. Changeset: 88dd6a94 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/88dd6a94 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java Reviewed-by: amenkov, cjplummer ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Tue Dec 22 13:45:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 13:45:57 GMT Subject: [jdk16] RFR: 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 22:44:51 GMT, Alex Menkov wrote: >> ProblemList three jstatd tests on Win* to reduce the noise in the JDK16 CI. > > Marked as reviewed by amenkov (Reviewer). @alexmenkov and @plummercj - Thanks for the fast reviews. ------------- PR: https://git.openjdk.java.net/jdk16/pull/57 From dcubed at openjdk.java.net Tue Dec 22 14:10:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 14:10:58 GMT Subject: RFR: 8258284: clean up issues with nested ThreadsListHandles [v2] In-Reply-To: References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: On Tue, 22 Dec 2020 09:32:55 GMT, Robbin Ehn wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolve @fisk CR about using Atomic::store(). > > Thanks @robehn - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1844 From dcubed at openjdk.java.net Tue Dec 22 14:11:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 14:11:00 GMT Subject: Integrated: 8258284: clean up issues with nested ThreadsListHandles In-Reply-To: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> References: <-4C-OlXUB4_OuQnZjUqpcIzBAWvryLNdo0YoxlwDaYg=.c0a160e8-d77c-4900-8b66-7d170d58c13b@github.com> Message-ID: <5u2QcfgIBQrls_Ybj0gMT1tL6xNGkU0CBCUItjcniZ8=.d94f1708-87b8-430a-b653-57b40d10c267@github.com> On Fri, 18 Dec 2020 17:07:27 GMT, Daniel D. Daugherty wrote: > While working on JDK-8231627, I discovered there were issues with nested > ThreadsListHandles. I added a new test to verify how ThreadsListHandles and > nested ThreadsListHandles are supposed to work. I found two bugs: > > 1) A failure to restore the expected _threads_hazard_ptr when a nested > ThreadsListHandle is destroyed. > > 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested > ThreadsListHandle is destroyed. > > The second failure mode is what tripped up my fix for JDK-8231627 so that > bug fix depends on this bug fix. > > Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment). This pull request has now been integrated. Changeset: 172af152 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/172af152 Stats: 720 lines in 4 files changed: 705 ins; 5 del; 10 mod 8258284: clean up issues with nested ThreadsListHandles Reviewed-by: eosterlund, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/1844 From dcubed at openjdk.java.net Tue Dec 22 17:03:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:03:05 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Message-ID: ProblemList two java/rmi/Naming tests on Windows in order to reduce the noise in the JDK16 CI. This is a trivial fix. ------------- Commit messages: - 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Changes: https://git.openjdk.java.net/jdk16/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258827 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/58/head:pull/58 PR: https://git.openjdk.java.net/jdk16/pull/58 From msheppar at openjdk.java.net Tue Dec 22 17:18:59 2020 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From rriggs at openjdk.java.net Tue Dec 22 17:18:59 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Dec 2020 17:18:59 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 17:14:24 GMT, Phil Race wrote: >> ProblemList two java/rmi/Naming tests on Windows in order to reduce the >> noise in the JDK16 CI. This is a trivial fix. > > overdue Thanks for the fast reviews! ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From prr at openjdk.java.net Tue Dec 22 17:19:00 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 22 Dec 2020 17:19:00 GMT Subject: [jdk16] RFR: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. overdue ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:19:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:19:01 GMT Subject: [jdk16] Integrated: 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows In-Reply-To: References: Message-ID: <49rEuRYk_yWrf0W7mmQ16jRX3BlcOw0Xj-2-jGaqDqQ=.3b9cb617-a8b6-4b56-8ce0-01f9d4dc3aa0@github.com> On Tue, 22 Dec 2020 16:56:33 GMT, Daniel D. Daugherty wrote: > ProblemList two java/rmi/Naming tests on Windows in order to reduce the > noise in the JDK16 CI. This is a trivial fix. This pull request has now been integrated. Changeset: eabc9030 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/eabc9030 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows Reviewed-by: rriggs, msheppar, prr ------------- PR: https://git.openjdk.java.net/jdk16/pull/58 From dcubed at openjdk.java.net Tue Dec 22 17:47:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 17:47:06 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Message-ID: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. ------------- Commit messages: - 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Changes: https://git.openjdk.java.net/jdk16/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258832 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk16/pull/59 From ccheung at openjdk.java.net Tue Dec 22 17:58:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 22 Dec 2020 17:58:59 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/59 From amenkov at openjdk.java.net Tue Dec 22 18:03:00 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 22 Dec 2020 18:03:00 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From dcubed at openjdk.java.net Tue Dec 22 19:01:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 19:01:57 GMT Subject: [jdk16] Integrated: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 17:42:49 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. This pull request has now been integrated. Changeset: 61e5e393 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/61e5e393 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 Reviewed-by: ccheung, amenkov ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From dcubed at openjdk.java.net Tue Dec 22 19:01:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Dec 2020 19:01:56 GMT Subject: [jdk16] RFR: 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 In-Reply-To: References: <0--UXghnOjFQwWtjeA7Y8qtCNWkU5U_adx2rGkqRvH0=.9707aade-fa1c-4405-8251-95f26386e8a4@github.com> Message-ID: On Tue, 22 Dec 2020 18:00:29 GMT, Alex Menkov wrote: >> This is a trivial fix to ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64. > > Marked as reviewed by amenkov (Reviewer). Thanks for the fast reviews! ------------- PR: https://git.openjdk.java.net/jdk16/pull/59 From cjplummer at openjdk.java.net Tue Dec 22 19:22:54 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Dec 2020 19:22:54 GMT Subject: RFR: 8258593: remove redundant codes in HeapObjectDumper In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 13:10:51 GMT, Lin Zang wrote: > 8258593: remove redundant codes in HeapObjectDumper Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1819 From lzang at openjdk.java.net Tue Dec 22 19:22:55 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 22 Dec 2020 19:22:55 GMT Subject: Integrated: 8258593: remove redundant codes in HeapObjectDumper In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 13:10:51 GMT, Lin Zang wrote: > 8258593: remove redundant codes in HeapObjectDumper This pull request has now been integrated. Changeset: 0ae78d4c Author: Lin Zang Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/0ae78d4c Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8258593: remove redundant codes in HeapObjectDumper Reviewed-by: coleenp, lfoltan, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/1819 From dcubed at openjdk.java.net Wed Dec 23 03:15:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 03:15:07 GMT Subject: [jdk16] RFR: 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated Message-ID: This is a trivial fix to MonitorList::unlink_deflated() to prevent it from crashing when called with an empty in-use MonitorList. That condition can only arise during the final audit during VM shutdown. This fix has been tested with runtime/logging/MonitorInflationTest.java combined with temporary debug code that delays the background threads that normally call Object.wait() very early in the VM's life. By delaying those background threads, we increase the likelihood of having an empty in-use MonitorList. The fix has also been tested with Mach5 Tier[1-3]. ------------- Commit messages: - 8257521 Changes: https://git.openjdk.java.net/jdk16/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257521 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk16/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/62/head:pull/62 PR: https://git.openjdk.java.net/jdk16/pull/62 From dcubed at openjdk.java.net Wed Dec 23 03:15:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 03:15:07 GMT Subject: [jdk16] RFR: 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 03:08:41 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to MonitorList::unlink_deflated() to prevent it from > crashing when called with an empty in-use MonitorList. That condition > can only arise during the final audit during VM shutdown. > > This fix has been tested with runtime/logging/MonitorInflationTest.java > combined with temporary debug code that delays the background threads > that normally call Object.wait() very early in the VM's life. By delaying those > background threads, we increase the likelihood of having an empty in-use > MonitorList. > > The fix has also been tested with Mach5 Tier[1-3]. @fisk - If you are around, please take a look at this one. ------------- PR: https://git.openjdk.java.net/jdk16/pull/62 From kbarrett at openjdk.java.net Wed Dec 23 12:08:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 23 Dec 2020 12:08:54 GMT Subject: [jdk16] RFR: 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 03:08:41 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to MonitorList::unlink_deflated() to prevent it from > crashing when called with an empty in-use MonitorList. That condition > can only arise during the final audit during VM shutdown. > > This fix has been tested with runtime/logging/MonitorInflationTest.java > combined with temporary debug code that delays the background threads > that normally call Object.wait() very early in the VM's life. By delaying those > background threads, we increase the likelihood of having an empty in-use > MonitorList. > > The fix has also been tested with Mach5 Tier[1-3]. Looks good, and agree the fix is trivial (though the analysis to get there is not trivial at all; thanks for the info in the bug report). ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/62 From hseigel at openjdk.java.net Wed Dec 23 13:48:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 13:48:01 GMT Subject: RFR: 8258837: Remove JVM option DisableStartThread Message-ID: Please review this small change to remove option DisableStartThread. The change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8258837: Remove JVM option DisableStartThread Changes: https://git.openjdk.java.net/jdk/pull/1879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1879&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258837 Stats: 19 lines in 2 files changed: 1 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1879/head:pull/1879 PR: https://git.openjdk.java.net/jdk/pull/1879 From kbarrett at openjdk.java.net Wed Dec 23 14:29:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 23 Dec 2020 14:29:55 GMT Subject: RFR: 8258837: Remove JVM option DisableStartThread In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 13:43:29 GMT, Harold Seigel wrote: > Please review this small change to remove option DisableStartThread. The change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. > > Thanks, Harold Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1879 From dcubed at openjdk.java.net Wed Dec 23 14:40:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 14:40:58 GMT Subject: [jdk16] RFR: 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 12:05:58 GMT, Kim Barrett wrote: >> This is a trivial fix to MonitorList::unlink_deflated() to prevent it from >> crashing when called with an empty in-use MonitorList. That condition >> can only arise during the final audit during VM shutdown. >> >> This fix has been tested with runtime/logging/MonitorInflationTest.java >> combined with temporary debug code that delays the background threads >> that normally call Object.wait() very early in the VM's life. By delaying those >> background threads, we increase the likelihood of having an empty in-use >> MonitorList. >> >> The fix has also been tested with Mach5 Tier[1-3]. > > Looks good, and agree the fix is trivial (though the analysis to get there is not trivial at all; thanks for the info in the bug report). @kimbarrett - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/62 From dcubed at openjdk.java.net Wed Dec 23 14:40:59 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 14:40:59 GMT Subject: [jdk16] Integrated: 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 03:08:41 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to MonitorList::unlink_deflated() to prevent it from > crashing when called with an empty in-use MonitorList. That condition > can only arise during the final audit during VM shutdown. > > This fix has been tested with runtime/logging/MonitorInflationTest.java > combined with temporary debug code that delays the background threads > that normally call Object.wait() very early in the VM's life. By delaying those > background threads, we increase the likelihood of having an empty in-use > MonitorList. > > The fix has also been tested with Mach5 Tier[1-3]. This pull request has now been integrated. Changeset: 9cd8e38a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/9cd8e38a Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk16/pull/62 From dcubed at openjdk.java.net Wed Dec 23 14:43:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 14:43:55 GMT Subject: RFR: 8258837: Remove JVM option DisableStartThread In-Reply-To: References: Message-ID: <1LHEjnGFJY_dsjNkeZSd3pkQwQ4R5cXWhctBAfKU1s0=.273664c1-0b92-47b2-9d10-0ce609369fbb@github.com> On Wed, 23 Dec 2020 13:43:29 GMT, Harold Seigel wrote: > Please review this small change to remove option DisableStartThread. The change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. > > Thanks, Harold Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1879 From hseigel at openjdk.java.net Wed Dec 23 14:47:55 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 14:47:55 GMT Subject: RFR: 8258837: Remove JVM option DisableStartThread In-Reply-To: <1LHEjnGFJY_dsjNkeZSd3pkQwQ4R5cXWhctBAfKU1s0=.273664c1-0b92-47b2-9d10-0ce609369fbb@github.com> References: <1LHEjnGFJY_dsjNkeZSd3pkQwQ4R5cXWhctBAfKU1s0=.273664c1-0b92-47b2-9d10-0ce609369fbb@github.com> Message-ID: <8902qONOenN6_peHOmQe51ANzYeMTlpqqayCfcKt7sk=.c9c68488-7015-43cc-812b-133350ae12bd@github.com> On Wed, 23 Dec 2020 14:41:04 GMT, Daniel D. Daugherty wrote: >> Please review this small change to remove option DisableStartThread. The change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Thumbs up. Thanks Kim and Dan for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1879 From hseigel at openjdk.java.net Wed Dec 23 14:47:56 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 14:47:56 GMT Subject: Integrated: 8258837: Remove JVM option DisableStartThread In-Reply-To: References: Message-ID: <6YGpzLIu7Wlmlr_j8undZQThU6d3-XM6ovsOg86Y8qM=.4c7088e5-14fd-4129-b300-8718c64b574c@github.com> On Wed, 23 Dec 2020 13:43:29 GMT, Harold Seigel wrote: > Please review this small change to remove option DisableStartThread. The change was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 24457350 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/24457350 Stats: 19 lines in 2 files changed: 1 ins; 9 del; 9 mod 8258837: Remove JVM option DisableStartThread Reviewed-by: kbarrett, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1879 From martin.doerr at sap.com Wed Dec 23 15:11:15 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Dec 2020 15:11:15 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging Message-ID: Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From amenkov at openjdk.java.net Wed Dec 23 20:30:04 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 20:21:12 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java > on Linux-X64. > > The test has been failing fairly frequently in the JDK17 CI when it is run with the > "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration > on linux-x64 so I'm going to ProblemList the test only on Linux-X64 Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 20:30:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Message-ID: This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64. The test has been failing fairly frequently in the JDK17 CI when it is run with the "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration on linux-x64 so I'm going to ProblemList the test only on Linux-X64 ------------- Commit messages: - 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Changes: https://git.openjdk.java.net/jdk/pull/1884/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1884&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258911 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1884.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1884/head:pull/1884 PR: https://git.openjdk.java.net/jdk/pull/1884 From amenkov at openjdk.java.net Wed Dec 23 20:30:04 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Dec 2020 20:30:04 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> On Wed, 23 Dec 2020 20:26:36 GMT, Alex Menkov wrote: >> This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java >> on Linux-X64. >> >> The test has been failing fairly frequently in the JDK17 CI when it is run with the >> "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration >> on linux-x64 so I'm going to ProblemList the test only on Linux-X64 > > Marked as reviewed by amenkov (Reviewer). Agreed that this is trivial fix ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 20:33:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:33:57 GMT Subject: Integrated: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: References: Message-ID: <-LSg054SDXlaEEkH5QT90MbSD8wcErL1C-m9VyyI3PQ=.fbf6d653-2257-4c2c-8a00-6c8434e1e89d@github.com> On Wed, 23 Dec 2020 20:21:12 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java > on Linux-X64. > > The test has been failing fairly frequently in the JDK17 CI when it is run with the > "-XX:NativeMemoryTracking=detail" option. We currently only specify that configuration > on linux-x64 so I'm going to ProblemList the test only on Linux-X64 This pull request has now been integrated. Changeset: e46edb55 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/e46edb55 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Reviewed-by: amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 20:33:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:33:56 GMT Subject: RFR: 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 In-Reply-To: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> References: <2Se2GVQpFdDWKCAkDDNiRgHGp6WLHuPZq3AXriQbTjA=.8bf1e4b8-9408-44a9-aacf-f7a9f4ae7539@github.com> Message-ID: <7DtSWRcblQK5-8aVdvT0venPIuSsNPh94Ggix8wYHzA=.fb0e335f-aba9-4df3-a182-87ca07d5fa1c@github.com> On Wed, 23 Dec 2020 20:27:11 GMT, Alex Menkov wrote: >> Marked as reviewed by amenkov (Reviewer). > > Agreed that this is trivial fix @alexmenkov - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1884 From dcubed at openjdk.java.net Wed Dec 23 21:05:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 21:05:07 GMT Subject: [jdk16] RFR: 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false Message-ID: This is a trivial test fix to add a retry loop to the code that exercises the WhiteBox deflateIdleMonitors() API. The failure reported in JDK-8257468 has only been seen one time in a Same-Binary-Run. I have not seen this failure in my lab with my stress testing nor has it been seen in Mach5. Tested with the modified test. ------------- Commit messages: - 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false Changes: https://git.openjdk.java.net/jdk16/pull/67/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=67&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257468 Stats: 18 lines in 1 file changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk16/pull/67.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/67/head:pull/67 PR: https://git.openjdk.java.net/jdk16/pull/67 From hseigel at openjdk.java.net Wed Dec 23 21:16:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 21:16:59 GMT Subject: [jdk16] RFR: 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false In-Reply-To: References: Message-ID: <8TvxxmqU8-R4Fe5moWeyfv16tNQF3uK8U-bSBZnN22g=.063e4306-6796-4813-83b7-422808d3cf33@github.com> On Wed, 23 Dec 2020 20:58:06 GMT, Daniel D. Daugherty wrote: > This is a trivial test fix to add a retry loop to the code that exercises the > WhiteBox deflateIdleMonitors() API. The failure reported in JDK-8257468 > has only been seen one time in a Same-Binary-Run. I have not seen this > failure in my lab with my stress testing nor has it been seen in Mach5. > > Tested with the modified test. The changes look good and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/67 From dcubed at openjdk.java.net Wed Dec 23 21:16:59 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 21:16:59 GMT Subject: [jdk16] RFR: 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false In-Reply-To: <8TvxxmqU8-R4Fe5moWeyfv16tNQF3uK8U-bSBZnN22g=.063e4306-6796-4813-83b7-422808d3cf33@github.com> References: <8TvxxmqU8-R4Fe5moWeyfv16tNQF3uK8U-bSBZnN22g=.063e4306-6796-4813-83b7-422808d3cf33@github.com> Message-ID: On Wed, 23 Dec 2020 21:12:20 GMT, Harold Seigel wrote: >> This is a trivial test fix to add a retry loop to the code that exercises the >> WhiteBox deflateIdleMonitors() API. The failure reported in JDK-8257468 >> has only been seen one time in a Same-Binary-Run. I have not seen this >> failure in my lab with my stress testing nor has it been seen in Mach5. >> >> Tested with the modified test. > > The changes look good and trivial. > Harold @hseigel - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk16/pull/67 From dcubed at openjdk.java.net Wed Dec 23 22:04:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 22:04:57 GMT Subject: [jdk16] RFR: 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false In-Reply-To: References: <8TvxxmqU8-R4Fe5moWeyfv16tNQF3uK8U-bSBZnN22g=.063e4306-6796-4813-83b7-422808d3cf33@github.com> Message-ID: On Wed, 23 Dec 2020 21:14:09 GMT, Daniel D. Daugherty wrote: >> The changes look good and trivial. >> Harold > > @hseigel - Thanks for the fast review! Mach5 Tier1 passed and the new test passed on all four platforms in Tier1. ------------- PR: https://git.openjdk.java.net/jdk16/pull/67 From dcubed at openjdk.java.net Wed Dec 23 22:04:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 22:04:58 GMT Subject: [jdk16] Integrated: 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 20:58:06 GMT, Daniel D. Daugherty wrote: > This is a trivial test fix to add a retry loop to the code that exercises the > WhiteBox deflateIdleMonitors() API. The failure reported in JDK-8257468 > has only been seen one time in a Same-Binary-Run. I have not seen this > failure in my lab with my stress testing nor has it been seen in Mach5. > > Tested with the modified test. This pull request has now been integrated. Changeset: 8b37c2c5 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk16/commit/8b37c2c5 Stats: 18 lines in 1 file changed: 15 ins; 0 del; 3 mod 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk16/pull/67 From david.holmes at oracle.com Thu Dec 24 06:08:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Dec 2020 16:08:43 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: Message-ID: <512ec914-709b-e38c-9a08-0bde8d702185@oracle.com> Ping! Thanks, David On 17/12/2020 9:54 pm, David Holmes wrote: > The fix in JDK-8193234 had an unintended consequence for the ReleaseArrayElements API, which is now fixed in this issue. > > I'd like to thank Mauro Lacy and Dmitry Timofeev for raising, analysing and discussing this issue. You can follow the thread here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/047248.html > > Although the fix itself is very basic I found a couple of other issues along the way, so I have staged the commits as follows for ease of understanding: > > Step 1: added a regression test for the current double-free problem > Step 2: Only try to print the GuardedMemory info in debug builds as it can lead to secondary crashes > Step 3: Fix incorrect function names in the error messages and cleanup formatting > Step 4: Revert the change from JDK-8193234 > Step 5: Add the memory-leak test from JDK-8193234 as a manual test > Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical > > Finally I had to tweak the test to fix a nativepath problem. > > Testing: > - tiers 1-4 (tier 4 includes the test run with -Xcheck:jni) > - local testing of the new tests > > Thanks, > David > > ------------- > > Commit messages: > - Updated test to fix nativepath problem. > - Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical > - Step 5: Add the memory-leak test from JDK-8193234 as a manual test > - Step 4: Revert the change from JDK-8193234 > - Step 3: Fix incorrect function names in the error messages and cleanup formatting. > - Step 2: Only try to print the GuardedMemory info in debug builds as it can trigger a secondary crash. > - 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 > > Changes: https://git.openjdk.java.net/jdk/pull/1816/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1816&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8258077 > Stats: 321 lines in 5 files changed: 303 ins; 6 del; 12 mod > Patch: https://git.openjdk.java.net/jdk/pull/1816.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1816/head:pull/1816 > > PR: https://git.openjdk.java.net/jdk/pull/1816 > From stuefe at openjdk.java.net Thu Dec 24 06:31:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 24 Dec 2020 06:31:57 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 09:07:07 GMT, David Holmes wrote: >> This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. >> >> Before: >> Signal Handlers: >> SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Now: >> Signal Handlers: >> SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none >> >> The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. >> >> It also introduces gtests for that function. >> >> I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. > > src/hotspot/os/posix/signals_posix.cpp line 1352: > >> 1350: LINUX_ONLY(sa.sa_flags &= SA_RESTORER_FLAG_MASK;) >> 1351: >> 1352: st->print("%10s: ", os::exception_name(sig, buf, buflen)); > > Where does the 10 come from? Why do we need to limit it? > A minor comment, but otherwise this seems quite reasonable. > > Thanks, > David Thanks, David! `%10s` is not a limit, its for alignment. It makes all the signal names nicely aligned (all colons end up in the same column). ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1839 From stuefe at openjdk.java.net Thu Dec 24 07:28:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 24 Dec 2020 07:28:09 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v2] In-Reply-To: References: Message-ID: > This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. > > Before: > Signal Handlers: > SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > Signal Handlers: > SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none > > The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. > > It also introduces gtests for that function. > > I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Coleen ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1839/files - new: https://git.openjdk.java.net/jdk/pull/1839/files/16e9ff9c..fa92e765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1839&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1839&range=00-01 Stats: 50 lines in 4 files changed: 26 ins; 7 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1839/head:pull/1839 PR: https://git.openjdk.java.net/jdk/pull/1839 From jwilhelm at openjdk.java.net Thu Dec 24 07:28:59 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 24 Dec 2020 07:28:59 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258916: javac/doclint reports broken HTML on multiline mailto links - 8253954: javac crash when compiling code with enhanced switch expressions with option -Xjcov - 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false - 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/1887/files Stats: 74 lines in 6 files changed: 68 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1887/head:pull/1887 PR: https://git.openjdk.java.net/jdk/pull/1887 From jwilhelm at openjdk.java.net Thu Dec 24 08:32:43 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 24 Dec 2020 08:32:43 GMT Subject: RFR: Merge jdk16 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 16 -> JDK 17 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 123 commits: - Merge - 8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64 Reviewed-by: prr - 8258856: VM build without C1/C2 fails after JDK-8243205 Reviewed-by: jiefu, kvn - 8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation Reviewed-by: weijun - 8258839: Remove JVM option ExitVMOnVerifyError Reviewed-by: iignatyev, dcubed, coleenp - 8258186: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: xuelei, alanb - 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64 Reviewed-by: amenkov - 8258557: Deproblemlist fixed problemlisted test Reviewed-by: trebari, serb - 8258837: Remove JVM option DisableStartThread Reviewed-by: kbarrett, dcubed - 8253368: TLS connection always receives close_notify exception Reviewed-by: xuelei - ... and 113 more: https://git.openjdk.java.net/jdk/compare/c398a828...f32ccfaa ------------- Changes: https://git.openjdk.java.net/jdk/pull/1887/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1887&range=01 Stats: 23854 lines in 636 files changed: 18445 ins; 3271 del; 2138 mod Patch: https://git.openjdk.java.net/jdk/pull/1887.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1887/head:pull/1887 PR: https://git.openjdk.java.net/jdk/pull/1887 From jwilhelm at openjdk.java.net Thu Dec 24 08:32:44 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 24 Dec 2020 08:32:44 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 07:23:41 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: 57217b58 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/57217b58 Stats: 74 lines in 6 files changed: 68 ins; 0 del; 6 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1887 From dcubed at openjdk.java.net Thu Dec 24 17:43:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 17:43:04 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads Message-ID: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the likelihood of crashes during error reporting. Uses Threads_lock->try_lock() for safety and restricts some reporting to when the Threads_lock has been acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make the current ThreadsList safe for reporting (depends on JDK-8258284). Also detects when the system ThreadsList (_java_thread_list) has changed and will warn that some of the reported info may now be stale. Two existing tests have been updated to reflect the use of a ThreadsListHandle in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. ------------- Commit messages: - 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads Changes: https://git.openjdk.java.net/jdk/pull/1891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231627 Stats: 68 lines in 3 files changed: 39 ins; 5 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/1891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1891/head:pull/1891 PR: https://git.openjdk.java.net/jdk/pull/1891 From dcubed at openjdk.java.net Thu Dec 24 17:43:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 17:43:04 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> Message-ID: On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty wrote: > A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the > likelihood of crashes during error reporting. Uses Threads_lock->try_lock() > for safety and restricts some reporting to when the Threads_lock has been > acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make > the current ThreadsList safe for reporting (depends on JDK-8258284). Also > detects when the system ThreadsList (_java_thread_list) has changed and > will warn that some of the reported info may now be stale. > > Two existing tests have been updated to reflect the use of a ThreadsListHandle > in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. @dholmes-ora, @fisk and @robehn - You folks might be interested in this Thread-SMR related robustness fix. It should help during error reporting. ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From dcubed at openjdk.java.net Thu Dec 24 18:08:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 18:08:55 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 11:45:53 GMT, David Holmes wrote: > The fix in JDK-8193234 had an unintended consequence for the ReleaseArrayElements API, which is now fixed in this issue. > > I'd like to thank Mauro Lacy and Dmitry Timofeev for raising, analysing and discussing this issue. You can follow the thread here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/047248.html > > Although the fix itself is very basic I found a couple of other issues along the way, so I have staged the commits as follows for ease of understanding: > > Step 1: added a regression test for the current double-free problem > Step 2: Only try to print the GuardedMemory info in debug builds as it can lead to secondary crashes > Step 3: Fix incorrect function names in the error messages and cleanup formatting > Step 4: Revert the change from JDK-8193234 > Step 5: Add the memory-leak test from JDK-8193234 as a manual test > Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical > > Finally I had to tweak the test to fix a nativepath problem. > > Testing: > - tiers 1-4 (tier 4 includes the test run with -Xcheck:jni) > - local testing of the new tests > > Thanks, > David I only have nits so it's your call on whether to make the changes. I like the new tests! Thanks for doing that. In what Tier do these new tests execute? Tier4 with "-Xcheck:jni" is a given, but do they also run in an earlier Tier or two? test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java line 113: > 111: } > 112: } > 113: for (int i = count; i 77: fill(arr, start, sliceLength); > 78: System.out.println("Array during: " + Arrays.toString(arr)); > 79: check(arr, (i+1) * sliceLength); nit - need spaces around '+'. test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c line 44: > 42: (*env)->ReleasePrimitiveArrayCritical(env, iarr, arr, JNI_COMMIT); > 43: } > 44: // we skip the test is the VM makes a copy - as it will definitely leak typo - s/is the/if the/ ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1816 From eosterlund at openjdk.java.net Thu Dec 24 22:03:54 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Dec 2020 22:03:54 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> Message-ID: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty wrote: > A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the > likelihood of crashes during error reporting. Uses Threads_lock->try_lock() > for safety and restricts some reporting to when the Threads_lock has been > acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make > the current ThreadsList safe for reporting (depends on JDK-8258284). Also > detects when the system ThreadsList (_java_thread_list) has changed and > will warn that some of the reported info may now be stale. > > Two existing tests have been updated to reflect the use of a ThreadsListHandle > in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. Looks good. We have something similar in the precious GC log code during error reporting. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1891 From dcubed at openjdk.java.net Thu Dec 24 22:09:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Dec 2020 22:09:55 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> Message-ID: On Thu, 24 Dec 2020 22:01:38 GMT, Erik ?sterlund wrote: >> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the >> likelihood of crashes during error reporting. Uses Threads_lock->try_lock() >> for safety and restricts some reporting to when the Threads_lock has been >> acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make >> the current ThreadsList safe for reporting (depends on JDK-8258284). Also >> detects when the system ThreadsList (_java_thread_list) has changed and >> will warn that some of the reported info may now be stale. >> >> Two existing tests have been updated to reflect the use of a ThreadsListHandle >> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. > > Looks good. We have something similar in the precious GC log code during error reporting. @fisk - Thanks for the review! And Merry Christmas Eve!! ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From eosterlund at openjdk.java.net Thu Dec 24 22:17:59 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Dec 2020 22:17:59 GMT Subject: RFR: 8231627: runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java fails because error occurred during printing all threads In-Reply-To: <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> References: <2UBK37oWUs8yehzfftzswNyDs53HFQ-hhexvGlcuJwk=.4a65ade2-cde6-45af-b599-de35339671c7@github.com> <0K6JjE__AaTO7A8wYchNtc19_87t1cSxnsmBllJCFW0=.2d3efed6-5f2c-481d-ba47-141538c63d9c@github.com> Message-ID: On Thu, 24 Dec 2020 22:01:38 GMT, Erik ?sterlund wrote: >> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the >> likelihood of crashes during error reporting. Uses Threads_lock->try_lock() >> for safety and restricts some reporting to when the Threads_lock has been >> acquired (depends on JDK-8256383). Uses a ThreadsListHandle to make >> the current ThreadsList safe for reporting (depends on JDK-8258284). Also >> detects when the system ThreadsList (_java_thread_list) has changed and >> will warn that some of the reported info may now be stale. >> >> Two existing tests have been updated to reflect the use of a ThreadsListHandle >> in ThreadsSMRSupport::print_info_on(). Mach5 Tier[1-6] testing has no regressions. > > Looks good. We have something similar in the precious GC log code during error reporting. > @fisk - Thanks for the review! And Merry Christmas Eve!! Merry Christmas to you too Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/1891 From david.holmes at oracle.com Sat Dec 26 09:45:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Dec 2020 19:45:05 +1000 Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers In-Reply-To: References: Message-ID: <302d5f99-1f84-f796-f482-a769e059ecf4@oracle.com> On 24/12/2020 4:31 pm, Thomas Stuefe wrote: > On Mon, 21 Dec 2020 09:07:07 GMT, David Holmes wrote: > >>> This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. >>> >>> Before: >>> Signal Handlers: >>> SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> >>> Now: >>> Signal Handlers: >>> SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >>> SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none >>> >>> The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. >>> >>> It also introduces gtests for that function. >>> >>> I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. >> >> src/hotspot/os/posix/signals_posix.cpp line 1352: >> >>> 1350: LINUX_ONLY(sa.sa_flags &= SA_RESTORER_FLAG_MASK;) >>> 1351: >>> 1352: st->print("%10s: ", os::exception_name(sig, buf, buflen)); >> >> Where does the 10 come from? Why do we need to limit it? > >> A minor comment, but otherwise this seems quite reasonable. >> >> Thanks, >> David > > Thanks, David! > > `%10s` is not a limit, its for alignment. It makes all the signal names nicely aligned (all colons end up in the same column). Ah! :) Thanks. David > ..Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1839 > From dholmes at openjdk.java.net Sat Dec 26 09:46:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 26 Dec 2020 09:46:57 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v2] In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 07:28:09 GMT, Thomas Stuefe wrote: >> This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. >> >> Before: >> Signal Handlers: >> SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Now: >> Signal Handlers: >> SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none >> >> The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. >> >> It also introduces gtests for that function. >> >> I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Coleen src/hotspot/os/posix/signals_posix.cpp line 811: > 809: os::print_function_and_library_name(tty, jvmHandler, buf, O_BUFLEN, true, true, true); > 810: tty->print_raw(" found:"); > 811: os::print_function_and_library_name(tty, thisHandler, buf, O_BUFLEN, true, true, true); These would benefit from using the same style as line 1361. No-one will remember what the three boolean flags represent. src/hotspot/share/runtime/os.hpp line 618: > 616: bool shorten_paths = true, > 617: bool demangle = true, > 618: bool strip_arguments = false); Are you actually relying on these having default values now? ------------- PR: https://git.openjdk.java.net/jdk/pull/1839 From stuefe at openjdk.java.net Mon Dec 28 07:52:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Dec 2020 07:52:09 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v3] In-Reply-To: References: Message-ID: > This patch changes the printout for our signal handlers in hs-err files and in `jcmd VM.info` to show the function names of the handlers. This is also interesting for CheckJNI. > > Before: > Signal Handlers: > SIGSEGV: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xbb8ff0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [libjvm.so+0xbb8e90], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xbb95b0], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Now: > Signal Handlers: > SIGSEGV: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [javaSignalHandler(int, siginfo_t*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR2: [SR_handler(int, siginfo_t*, ucontext*)+0 in libjvm.so], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [UserHandler(int, void*, void*)+0 in libjvm.so], sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGTRAP: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none > > The patch introduces a new function, `os::print_function_and_library_name`, which prints a combined function and library name. > > It also introduces gtests for that function. > > I plan to use it in other places to, and unify similar coding, e.g. when printing stack traces (NMT, VMError) or pointer locations (os::print_location). But I leave that for a future RFE. Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - style changes - Fix Windows gtests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1839/files - new: https://git.openjdk.java.net/jdk/pull/1839/files/fa92e765..83185596 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1839&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1839&range=01-02 Stats: 18 lines in 2 files changed: 11 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1839/head:pull/1839 PR: https://git.openjdk.java.net/jdk/pull/1839 From stuefe at openjdk.java.net Mon Dec 28 07:52:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Dec 2020 07:52:11 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v2] In-Reply-To: References: Message-ID: <05PmV-4ip_dXUWW3oLQIlhvHVc3ruQaBYAdzA_EPBKc=.2f44212a-d7dd-48f1-8f18-43e474a3ddd6@github.com> On Sat, 26 Dec 2020 09:44:22 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Coleen > > src/hotspot/share/runtime/os.hpp line 618: > >> 616: bool shorten_paths = true, >> 617: bool demangle = true, >> 618: bool strip_arguments = false); > > Are you actually relying on these having default values now? I think it makes sense. The scratch buffer arguments are useful during error handling but a bit cumbersome in normal situations. Since I want this to be a general purpose function, I make the scratch buffer optional. Btw, do you object against the `alloca` in the implementation? We use it in some few other places too. But it was a coin toss really whether to use (raw) malloc instead. > src/hotspot/os/posix/signals_posix.cpp line 811: > >> 809: os::print_function_and_library_name(tty, jvmHandler, buf, O_BUFLEN, true, true, true); >> 810: tty->print_raw(" found:"); >> 811: os::print_function_and_library_name(tty, thisHandler, buf, O_BUFLEN, true, true, true); > > These would benefit from using the same style as line 1361. No-one will remember what the three boolean flags represent. You are right. I reworked the style. ------------- PR: https://git.openjdk.java.net/jdk/pull/1839 From stuefe at openjdk.java.net Mon Dec 28 07:52:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Dec 2020 07:52:12 GMT Subject: RFR: JDK-8258606: os::print_signal_handlers() should resolve the function name of the handlers [v3] In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 13:17:12 GMT, Coleen Phillimore wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - style changes >> - Fix Windows gtests > > src/hotspot/share/runtime/os.cpp line 906: > >> 904: } >> 905: int offset = 0; >> 906: const bool have_function_name = dll_address_to_function_name(addr, p, buflen, > > So this function includes the arguments in the string that it returns? The arguments make the output long and don't add anything helpful in my opinion, but it's not really worth having the code to strip them out. Hi Coleen, thanks for the review! You are right. I modified the patch and removed the arguments, which did not make the code much more complex but reads better. Now it looks like this: 657 Signal Handlers: 658 SIGSEGV: crash_handler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 659 SIGBUS: crash_handler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 660 SIGFPE: crash_handler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 661 SIGPIPE: javaSignalHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 662 SIGXFSZ: javaSignalHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 663 SIGILL: crash_handler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 664 SIGUSR2: SR_handler+0 in libjvm.so, sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO 665 SIGHUP: UserHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 666 SIGINT: UserHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 667 SIGTERM: UserHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 668 SIGQUIT: UserHandler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO 669 SIGTRAP: crash_handler+0 in libjvm.so, sa_mask[0]=11100100010111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO ------------- PR: https://git.openjdk.java.net/jdk/pull/1839 From martin.doerr at sap.com Mon Dec 28 13:17:47 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 28 Dec 2020 13:17:47 +0000 Subject: [11u] RFR: 8255544: Create a checked cast Message-ID: Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From dholmes at openjdk.java.net Tue Dec 29 07:10:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 29 Dec 2020 07:10:20 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 [v2] In-Reply-To: References: Message-ID: > The fix in JDK-8193234 had an unintended consequence for the ReleaseArrayElements API, which is now fixed in this issue. > > I'd like to thank Mauro Lacy and Dmitry Timofeev for raising, analysing and discussing this issue. You can follow the thread here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/047248.html > > Although the fix itself is very basic I found a couple of other issues along the way, so I have staged the commits as follows for ease of understanding: > > Step 1: added a regression test for the current double-free problem > Step 2: Only try to print the GuardedMemory info in debug builds as it can lead to secondary crashes > Step 3: Fix incorrect function names in the error messages and cleanup formatting > Step 4: Revert the change from JDK-8193234 > Step 5: Add the memory-leak test from JDK-8193234 as a manual test > Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical > > Finally I had to tweak the test to fix a nativepath problem. > > Testing: > - tiers 1-4 (tier 4 includes the test run with -Xcheck:jni) > - local testing of the new tests > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix minor nits from Dan's review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1816/files - new: https://git.openjdk.java.net/jdk/pull/1816/files/8786d584..b989bc52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1816&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1816&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1816/head:pull/1816 PR: https://git.openjdk.java.net/jdk/pull/1816 From david.holmes at oracle.com Tue Dec 29 07:14:13 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Dec 2020 17:14:13 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: Message-ID: <25576442-2f57-980b-ac04-d7a562a85dfa@oracle.com> Hi Dan, Thanks for the Review. On 25/12/2020 4:08 am, Daniel D.Daugherty wrote: > On Thu, 17 Dec 2020 11:45:53 GMT, David Holmes wrote: > >> The fix in JDK-8193234 had an unintended consequence for the ReleaseArrayElements API, which is now fixed in this issue. >> >> I'd like to thank Mauro Lacy and Dmitry Timofeev for raising, analysing and discussing this issue. You can follow the thread here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/047248.html >> >> Although the fix itself is very basic I found a couple of other issues along the way, so I have staged the commits as follows for ease of understanding: >> >> Step 1: added a regression test for the current double-free problem >> Step 2: Only try to print the GuardedMemory info in debug builds as it can lead to secondary crashes >> Step 3: Fix incorrect function names in the error messages and cleanup formatting >> Step 4: Revert the change from JDK-8193234 >> Step 5: Add the memory-leak test from JDK-8193234 as a manual test >> Step 6: Fix the JNI_COMMIT memory leak only for the case of ReleasePrimitiveArrayCritical >> >> Finally I had to tweak the test to fix a nativepath problem. >> >> Testing: >> - tiers 1-4 (tier 4 includes the test run with -Xcheck:jni) >> - local testing of the new tests >> >> Thanks, >> David > > I only have nits so it's your call on whether to make the changes. All nits fixed. > I like the new tests! Thanks for doing that. In what Tier do these > new tests execute? Tier4 with "-Xcheck:jni" is a given, but do > they also run in an earlier Tier or two? TestCheckedReleaseCriticalArray won't execute in any tier as it is a manual test. TestCheckedReleaseArrayElements runs in tier1 like the majority of runtime tests. It likely runs in tier4 as well but that isn't really relevant as it already sets -Xcheck:jni on the launched VM. Thanks, David > test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java line 113: > >> 111: } >> 112: } >> 113: for (int i = count; i > nit - need space after '<'. > > test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java line 79: > >> 77: fill(arr, start, sliceLength); >> 78: System.out.println("Array during: " + Arrays.toString(arr)); >> 79: check(arr, (i+1) * sliceLength); > > nit - need spaces around '+'. > > test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c line 44: > >> 42: (*env)->ReleasePrimitiveArrayCritical(env, iarr, arr, JNI_COMMIT); >> 43: } >> 44: // we skip the test is the VM makes a copy - as it will definitely leak > > typo - s/is the/if the/ > > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1816 > From goetz.lindenmaier at sap.com Tue Dec 29 15:58:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Dec 2020 15:58:50 +0000 Subject: [11u] RFR: 8255544: Create a checked cast In-Reply-To: References: Message-ID: Hi, Ok, so there is only the definition of the checked_cast remaining. Looks good. Best regards, Goetz. From: Doerr, Martin Sent: Monday, December 28, 2020 2:18 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8255544: Create a checked cast Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Tue Dec 29 16:00:12 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Dec 2020 16:00:12 +0000 Subject: [11u] RFR: 8255544: Create a checked cast In-Reply-To: References: Message-ID: Hi G?tz, > Ok, so there is only the definition of the checked_cast remaining. Right. It's needed for future backports. Thanks for the review! Best regards, Martin From: Lindenmaier, Goetz Sent: Dienstag, 29. Dezember 2020 16:59 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8255544: Create a checked cast Hi, Ok, so there is only the definition of the checked_cast remaining. Looks good. Best regards, Goetz. From: Doerr, Martin > Sent: Monday, December 28, 2020 2:18 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8255544: Create a checked cast Hi, JDK-8255544 is backported to 11.0.11-oracle. I'd like to backport it for parity. And it's required by other backports. Change doesn't apply cleanly: globalDefinitions.hpp: I had to apply the hunk manually because of unrelated context changes. heap.cpp: Doesn't apply because JDK-8231460 is not in 11u. I suggest to skip it. Bug: https://bugs.openjdk.java.net/browse/JDK-8255544 Original change: https://github.com/openjdk/jdk/commit/3302d3ad 11u backport: http://cr.openjdk.java.net/~mdoerr/8255544_checked_cast_11u/webrev.00/ Please review. Best regards, Martin From goetz.lindenmaier at sap.com Wed Dec 30 10:14:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Dec 2020 10:14:03 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging In-Reply-To: References: Message-ID: Hi Martin, I had a look at your change. I also compared it with the original version that has both involved changes. You might want to adapt the comment: - // hence it is skipped in handshake_process_by_vmthread. + // hence it is skipped in handshake_try_process_by_vmthread. I don't need a new webrev. Looks good. Best regards, Goetz. From: Doerr, Martin Sent: Wednesday, December 23, 2020 4:11 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: [11u] RFR: 8234742: Improve handshake logging Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From martin.doerr at sap.com Wed Dec 30 10:57:01 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Dec 2020 10:57:01 +0000 Subject: [11u] RFR: 8234742: Improve handshake logging In-Reply-To: References: Message-ID: Hi G?tz, thanks for the review! Pushed with your suggestion. Best regards, Martin From: Lindenmaier, Goetz Sent: Mittwoch, 30. Dezember 2020 11:14 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: [11u] RFR: 8234742: Improve handshake logging Hi Martin, I had a look at your change. I also compared it with the original version that has both involved changes. You might want to adapt the comment: - // hence it is skipped in handshake_process_by_vmthread. + // hence it is skipped in handshake_try_process_by_vmthread. I don't need a new webrev. Looks good. Best regards, Goetz. From: Doerr, Martin > Sent: Wednesday, December 23, 2020 4:11 PM To: hotspot-runtime-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: [11u] RFR: 8234742: Improve handshake logging Hi, JDK-8234742 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly at all, mainly because JDK-8244340 was integrated before this one which was in the wrong order. (Failing hunks are listed here: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/8234742_handshake_failing_hunks.txt) So my 11u backport is supposed to reflect the state of both changes integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8234742 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/c2ce3849c62f Other change which was backported in the wrong order and from which I've taken small parts: https://hg.openjdk.java.net/jdk/jdk/rev/67a435ce2dc2 11u backport: http://cr.openjdk.java.net/~mdoerr/8234742_handshake_11u/webrev.00/ Please review. Best regards, Martin From glaubitz at openjdk.java.net Wed Dec 30 22:47:01 2020 From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz) Date: Wed, 30 Dec 2020 22:47:01 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:17:07 GMT, Vladimir Ivanov wrote: >> Marked as reviewed by kbarrett (Reviewer). > > Thanks for the reviews, Kim, Coleen, and David. The change in 044616bd71ab82f0f67670152cecbabfee83d00c breaks the build on m68k which uses a native alignment of 16 bits despite being a 32-bit architecture as a result of the m68k SysV ABI. In file included from /<>/src/hotspot/share/ci/ciEnv.hpp:35, from /<>/src/hotspot/share/ci/compilerInterface.hpp:32, from /<>/src/hotspot/share/compiler/abstractCompiler.hpp:28, from /<>/src/hotspot/share/compiler/abstractCompiler.cpp:25: /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ gmake[4]: *** [lib/CompileJvm.gmk:143: /<>/build/hotspot/variant-zero/libjvm/objs/abstractCompiler.o] Error 1 gmake[3]: *** [make/Main.gmk:252: hotspot-zero-libs] Error 2 gmake[3]: *** Waiting for unfinished jobs.... Full log: https://buildd.debian.org/status/fetch.php?pkg=openjdk-16&arch=m68k&ver=16%7E29-1&stamp=1609359094&raw=0 Any suggestion on a quick fix (before I start digging myself)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From ysuenaga at openjdk.java.net Thu Dec 31 00:18:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 31 Dec 2020 00:18:07 GMT Subject: RFR: 8259008: ArithmeticException was thrown at "Monitor Cache Dump" on HSDB Message-ID: <0iZCD-O-3IYg8mATfnTUH1DH7oLF-mPFNWOuyKVqEnE=.62161c51-36d9-4bd0-8505-c027258d18df@github.com> I saw the exception as following when I chose "Monitor Cache Dump" menu on HSDB: Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(MonitorCacheDumpPanel.java:92) at jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(MonitorCacheDumpPanel.java:59) at jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(HSDB.java:1556) at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$16.actionPerformed(HSDB.java:338) at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972) at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313) at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405) at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262) at java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:374) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1022) at java.desktop/javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1066) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6617) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6382) at java.desktop/java.awt.Container.processEvent(Container.java:2264) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4993) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2322) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4825) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4934) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4563) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4504) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2308) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2773) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4825) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) Caused by: java.lang.ArithmeticException: / by zero at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(ObjectSynchronizer.java:55) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer$1.update(ObjectSynchronizer.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:578) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ObjectSynchronizer.(ObjectSynchronizer.java:38) ... 41 more This exception seems to be caused by [JDK-8253064](https://bugs.openjdk.java.net/browse/JDK-8253064). It has changed `ObjectSynchronizer`, but it has not changed SA code. ------------- Commit messages: - 8259008: ArithmeticException was thrown at "Monitor Cache Dump" on HSDB Changes: https://git.openjdk.java.net/jdk/pull/1910/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1910&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259008 Stats: 182 lines in 5 files changed: 130 ins; 38 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1910.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1910/head:pull/1910 PR: https://git.openjdk.java.net/jdk/pull/1910 From david.holmes at oracle.com Thu Dec 31 03:09:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Dec 2020 13:09:59 +1000 Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: On 31/12/2020 8:47 am, John Paul Adrian Glaubitz wrote: > On Tue, 8 Dec 2020 11:17:07 GMT, Vladimir Ivanov wrote: > >>> Marked as reviewed by kbarrett (Reviewer). >> >> Thanks for the reviews, Kim, Coleen, and David. > > The change in 044616bd71ab82f0f67670152cecbabfee83d00c breaks the build on m68k which uses a native alignment of 16 bits despite being a 32-bit architecture as a result of the m68k SysV ABI. Isn't m68K a zero-only platform? In which case why are these files even part of the build let alone runtime? > In file included from /<>/src/hotspot/share/ci/ciEnv.hpp:35, > from /<>/src/hotspot/share/ci/compilerInterface.hpp:32, > from /<>/src/hotspot/share/compiler/abstractCompiler.hpp:28, > from /<>/src/hotspot/share/compiler/abstractCompiler.cpp:25: > /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': > /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align > 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ > gmake[4]: *** [lib/CompileJvm.gmk:143: /<>/build/hotspot/variant-zero/libjvm/objs/abstractCompiler.o] Error 1 > gmake[3]: *** [make/Main.gmk:252: hotspot-zero-libs] Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > > Full log: https://buildd.debian.org/status/fetch.php?pkg=openjdk-16&arch=m68k&ver=16%7E29-1&stamp=1609359094&raw=0 > > Any suggestion on a quick fix (before I start digging myself)? Exclude the assertion in a zero build? David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1478 > From glaubitz at openjdk.java.net Thu Dec 31 10:13:54 2020 From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz) Date: Thu, 31 Dec 2020 10:13:54 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor [v5] In-Reply-To: References: Message-ID: On Wed, 30 Dec 2020 22:43:46 GMT, John Paul Adrian Glaubitz wrote: >> Thanks for the reviews, Kim, Coleen, and David. > > The change in 044616bd71ab82f0f67670152cecbabfee83d00c breaks the build on m68k which uses a native alignment of 16 bits despite being a 32-bit architecture as a result of the m68k SysV ABI. > > In file included from /<>/src/hotspot/share/ci/ciEnv.hpp:35, > from /<>/src/hotspot/share/ci/compilerInterface.hpp:32, > from /<>/src/hotspot/share/compiler/abstractCompiler.hpp:28, > from /<>/src/hotspot/share/compiler/abstractCompiler.cpp:25: > /<>/src/hotspot/share/oops/methodData.hpp: In constructor 'MethodData::CompilerCounters::CompilerCounters()': > /<>/src/hotspot/share/oops/methodData.hpp:1987:55: error: static assertion failed: align > 1987 | static_assert(sizeof(_trap_hist) % HeapWordSize == 0, "align"); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ > gmake[4]: *** [lib/CompileJvm.gmk:143: /<>/build/hotspot/variant-zero/libjvm/objs/abstractCompiler.o] Error 1 > gmake[3]: *** [make/Main.gmk:252: hotspot-zero-libs] Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > > Full log: https://buildd.debian.org/status/fetch.php?pkg=openjdk-16&arch=m68k&ver=16%7E29-1&stamp=1609359094&raw=0 > > Any suggestion on a quick fix (before I start digging myself)? > Isn't m68K a zero-only platform? In which case why are these files even part of the build let alone runtime? Yes, it's a Zero port. But apparently the files are being used anyway. > Exclude the assertion in a zero build? Thanks, I'll do that. I wasn't sure whether the code was relevant for Zero or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478