From dcubed at openjdk.java.net Sat May 1 00:19:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 1 May 2021 00:19:39 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary "@library /test/lib". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/3b4004d8..bac63a79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From dholmes at openjdk.java.net Sat May 1 04:55:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 1 May 2021 04:55:53 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" [v2] In-Reply-To: <48rwfXGoo5MF4daRoiJ_6-mPKs6S49GOyp6wk45i60o=.1b9ebaa6-e85f-4abe-9222-8aa01903d9f5@github.com> References: <48rwfXGoo5MF4daRoiJ_6-mPKs6S49GOyp6wk45i60o=.1b9ebaa6-e85f-4abe-9222-8aa01903d9f5@github.com> Message-ID: On Fri, 30 Apr 2021 13:08:15 GMT, Per Liden wrote: >> This patch addresses two issues with the StringTableCleaningTest test. >> >> 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. >> >> 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. >> >> This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. >> >> This patch also removes the test from the ProblemList. >> >> Testing: >> * Passed Tier1-3. >> * Manual testing of StringTableCleaningTest with various GCs. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from David I had assumed you wanted to see the output even on success. :) Update is fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3815 From vromero at openjdk.java.net Sun May 2 02:10:26 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 2 May 2021 02:10:26 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04-05 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From david.holmes at oracle.com Sun May 2 05:48:22 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 2 May 2021 15:48:22 +1000 Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com> Message-ID: <47438cf3-dc38-f77b-e558-60eb2d7b707c@oracle.com> On 1/05/2021 6:57 am, Daniel D.Daugherty wrote: > On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137: >> >>> 135: } >>> 136: >>> 137: System.exit(run(timeMax, System.out) + exit_delta); >> >> jtreg tests don't use System.exit! > > Hmmm... that's generally true, but this is a test that must be run as > "othervm" so this style of exit with the "+ exit_delta" logic has been > used for these kinds of stress tests. I think this style came from the > VMTestbase tests and I've used it with other stress tests. Hmmm... this is a legacy style/approach that is not necessary any more. If the test fails it should throw an exception from the main thread and that will produce a non-zero exit value. I think seeing this legacy style in new tests will just confuse people. YMMV. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3478 > From redestad at openjdk.java.net Sun May 2 21:25:10 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 2 May 2021 21:25:10 GMT Subject: RFR: 8266412: Remove redundant TemplateInterpreter entries Message-ID: This patch trivially removes two redundant entry point generation calls that I accidentally forgot to remove after a refactoring in https://bugs.openjdk.java.net/browse/JDK-8255271 A very slim improvement (~70k fewer instructions executed on bootstrap), but still.. ------------- Commit messages: - Remove left-over itos entries Changes: https://git.openjdk.java.net/jdk/pull/3833/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3833&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266412 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3833.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3833/head:pull/3833 PR: https://git.openjdk.java.net/jdk/pull/3833 From jiefu at openjdk.java.net Sun May 2 23:19:57 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 2 May 2021 23:19:57 GMT Subject: RFR: 8266412: Remove redundant TemplateInterpreter entries In-Reply-To: References: Message-ID: On Sun, 2 May 2021 21:19:27 GMT, Claes Redestad wrote: > This patch trivially removes two redundant entry point generation calls that I accidentally forgot to remove after a refactoring in https://bugs.openjdk.java.net/browse/JDK-8255271 > > A very slim improvement (~70k fewer instructions executed on bootstrap), but still.. Looks good to me. Thanks. ------------- Marked as reviewed by jiefu (Committer). PR: https://git.openjdk.java.net/jdk/pull/3833 From stuefe at openjdk.java.net Mon May 3 04:12:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 3 May 2021 04:12:13 GMT Subject: RFR: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping Message-ID: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266222 Stats: 25 lines in 1 file changed: 19 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3765/head:pull/3765 PR: https://git.openjdk.java.net/jdk/pull/3765 From dholmes at openjdk.java.net Mon May 3 04:16:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 3 May 2021 04:16:50 GMT Subject: RFR: 8266412: Remove redundant TemplateInterpreter entries In-Reply-To: References: Message-ID: <5a1y3XaybN-MOw8Sk6e5kLutzE6Piy3s_Xr3eN9AtG0=.3ab2cac1-9536-48bc-9e0b-7f3deb4fed46@github.com> On Sun, 2 May 2021 21:19:27 GMT, Claes Redestad wrote: > This patch trivially removes two redundant entry point generation calls that I accidentally forgot to remove after a refactoring in https://bugs.openjdk.java.net/browse/JDK-8255271 > > A very slim improvement (~70k fewer instructions executed on bootstrap), but still.. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3833 From stuefe at openjdk.java.net Mon May 3 05:57:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 3 May 2021 05:57:00 GMT Subject: RFR: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping In-Reply-To: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> References: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> Message-ID: On Wed, 28 Apr 2021 15:35:47 GMT, Thomas Stuefe wrote: > In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). > > When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. > > However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. > > After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. > > Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). > > This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. > > Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. src/hotspot/os/aix/os_aix.cpp line 1992: > 1990: vmembk_t* const vmi = vmembk_find(addr); > 1991: guarantee0(vmi); > 1992: vmi->assert_is_valid_subrange(addr, size); Reviewer note: this is unrelated to the problem, I just lifted the assert call from both branches and made it independent from debug/release. ------------- PR: https://git.openjdk.java.net/jdk/pull/3765 From pliden at openjdk.java.net Mon May 3 07:32:53 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 3 May 2021 07:32:53 GMT Subject: Integrated: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" In-Reply-To: References: Message-ID: <2mdCC363x33hLxR6sjHJiuR1-KLoVwzp8XBA9FuZrB4=.d6b7aa71-b2ef-4748-9c39-2d00e2b6b90e@github.com> On Fri, 30 Apr 2021 12:08:00 GMT, Per Liden wrote: > This patch addresses two issues with the StringTableCleaningTest test. > > 1) The test doesn't fully take into account that a concurrent GC might not complete (it can abort if the VM wants to terminate). findCallback() should return -1 if no callbacks are found, instead of failing the test. > > 2) The regexp patterns used for ZGC needs to be more exact. The end pattern now also matches aborted GCs, which it shouldn't. This leads to "Garbage Collection (*) Aborted" being incorrectly matched as a GC end. > > This patch also makes sure the output from the test VM ends up in the test log, otherwise it's impossible to tell what went wrong if this test fails in the future. > > This patch also removes the test from the ProblemList. > > Testing: > * Passed Tier1-3. > * Manual testing of StringTableCleaningTest with various GCs. This pull request has now been integrated. Changeset: c5dc657f Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/c5dc657f0be90bd594663dcc612f40a930c2bbe7 Stats: 6 lines in 2 files changed: 1 ins; 1 del; 4 mod 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3815 From pliden at openjdk.java.net Mon May 3 07:32:52 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 3 May 2021 07:32:52 GMT Subject: RFR: 8266056: runtime/stringtable/StringTableCleaningTest.java failed with "RuntimeException: Missing Callback in [10, 11]" [v2] In-Reply-To: References: <48rwfXGoo5MF4daRoiJ_6-mPKs6S49GOyp6wk45i60o=.1b9ebaa6-e85f-4abe-9222-8aa01903d9f5@github.com> Message-ID: On Sat, 1 May 2021 04:52:57 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from David > > I had assumed you wanted to see the output even on success. :) > > Update is fine. > > Thanks, > David Thanks @dholmes-ora and @coleenp for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3815 From redestad at openjdk.java.net Mon May 3 09:25:52 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 3 May 2021 09:25:52 GMT Subject: RFR: 8266412: Remove redundant TemplateInterpreter entries In-Reply-To: References: Message-ID: On Sun, 2 May 2021 23:17:26 GMT, Jie Fu wrote: >> This patch trivially removes two redundant entry point generation calls that I accidentally forgot to remove after a refactoring in https://bugs.openjdk.java.net/browse/JDK-8255271 >> >> A very slim improvement (~70k fewer instructions executed on bootstrap), but still.. > > Looks good to me. > Thanks. @DamonFool @dholmes-ora: thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3833 From redestad at openjdk.java.net Mon May 3 09:25:53 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 3 May 2021 09:25:53 GMT Subject: Integrated: 8266412: Remove redundant TemplateInterpreter entries In-Reply-To: References: Message-ID: On Sun, 2 May 2021 21:19:27 GMT, Claes Redestad wrote: > This patch trivially removes two redundant entry point generation calls that I accidentally forgot to remove after a refactoring in https://bugs.openjdk.java.net/browse/JDK-8255271 > > A very slim improvement (~70k fewer instructions executed on bootstrap), but still.. This pull request has now been integrated. Changeset: 05cfac9f Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/05cfac9f5bf07c3c4422f797a61b6e1b8410ce1b Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8266412: Remove redundant TemplateInterpreter entries Reviewed-by: jiefu, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3833 From jlahoda at openjdk.java.net Mon May 3 16:41:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 3 May 2021 16:41:54 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From redestad at openjdk.java.net Mon May 3 23:41:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 3 May 2021 23:41:09 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v4] In-Reply-To: References: Message-ID: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Restructure initializer, reuse AdapterSignatureIterator in create_native_wrapper, minor improvements ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3706/files - new: https://git.openjdk.java.net/jdk/pull/3706/files/2bbb1198..2e299fc7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3706&range=02-03 Stats: 37 lines in 1 file changed: 10 ins; 21 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3706.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3706/head:pull/3706 PR: https://git.openjdk.java.net/jdk/pull/3706 From dholmes at openjdk.java.net Tue May 4 00:48:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 00:48:07 GMT Subject: RFR: 8255566: Add size validation when parsing values from VersionProps Message-ID: java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. Testing: tiers 1-3 Thanks, David ------------- Commit messages: - Add missing include - 8255566: Add size validation when parsing values from VersionProps Changes: https://git.openjdk.java.net/jdk/pull/3848/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3848&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255566 Stats: 38 lines in 2 files changed: 6 ins; 15 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3848.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3848/head:pull/3848 PR: https://git.openjdk.java.net/jdk/pull/3848 From iklam at openjdk.java.net Tue May 4 01:40:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 4 May 2021 01:40:52 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v4] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 23:41:09 GMT, Claes Redestad wrote: >> This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. >> >> Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. >> >> This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Restructure initializer, reuse AdapterSignatureIterator in create_native_wrapper, minor improvements The latest version LGTM. Thanks for also testing out the alternative optimizations. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3706 From iklam at openjdk.java.net Tue May 4 01:48:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 4 May 2021 01:48:52 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:04:54 GMT, Claes Redestad wrote: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Looks good to me. Just a minor nit about asserts. For other reviewers, you can get better diffs by adding `?w=1` to ignore whitespace changes. I.e., `https://github.com/openjdk/jdk/pull/3798/files?w=1` src/hotspot/share/interpreter/abstractInterpreter.cpp line 143: > 141: // _dsqrt will be selected for both Math::sqrt and StrictMath::sqrt, but the latter > 142: // is native. Keep treating it like a native method in the interpreter > 143: case vmIntrinsics::_dsqrt: return m->is_native() ? native : java_lang_math_sqrt; Maybe we should add an assert that m must be one of the two methods mentioned by the above comment? ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3798 From rehn at openjdk.java.net Tue May 4 06:18:50 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 4 May 2021 06:18:50 GMT Subject: RFR: 8255566: Add size validation when parsing values from VersionProps In-Reply-To: References: Message-ID: On Tue, 4 May 2021 00:38:54 GMT, David Holmes wrote: > java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. > > Testing: tiers 1-3 > > Thanks, > David Looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3848 From david.holmes at oracle.com Tue May 4 07:35:10 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 May 2021 17:35:10 +1000 Subject: RFR: 8255566: Add size validation when parsing values from VersionProps In-Reply-To: References: Message-ID: On 4/05/2021 4:18 pm, Robbin Ehn wrote: > On Tue, 4 May 2021 00:38:54 GMT, David Holmes wrote: > >> java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > Looks good. Thanks Robbin! David > ------------- > > Marked as reviewed by rehn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3848 > From stuefe at openjdk.java.net Tue May 4 15:45:10 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 4 May 2021 15:45:10 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size Message-ID: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. Better would be to use a numerical index array of offset values, which could be safely copied. And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. Testing: - manually jtreg runtime/logging - manually gtests - Will run more tests tonight ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3855/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3855&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266503 Stats: 52 lines in 3 files changed: 48 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3855/head:pull/3855 PR: https://git.openjdk.java.net/jdk/pull/3855 From iklam at openjdk.java.net Tue May 4 17:39:53 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 4 May 2021 17:39:53 GMT Subject: RFR: 8255566: Add size validation when parsing values from VersionProps In-Reply-To: References: Message-ID: On Tue, 4 May 2021 00:38:54 GMT, David Holmes wrote: > java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. > > Testing: tiers 1-3 > > Thanks, > David LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3848 From iklam at openjdk.java.net Tue May 4 18:17:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 4 May 2021 18:17:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Looks reasonable to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Tue May 4 19:24:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 4 May 2021 19:24:56 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks Ioi, and thanks for updating the description. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From xliu at openjdk.java.net Tue May 4 20:25:52 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 4 May 2021 20:25:52 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight I think the idea lookup table of offsets is great. Also compilers can make use of SIMD instructions to generate more efficient copying code. But I think we still need a custom copy constructor. Here is why. 1. the internal representation of decorations is compact. LogDecorations::create_decorations() puts all non-trivial decorations together. 2. the average use of _decorations_buffer is just 1/10 of its capacity or DecorationsBufferSize. I dump all decorations : java -Xlog:async -Xlog:all=trace:file=hotspot.log --version By default, its decorators is LogDecorators::DefaultDecoratorsMask = (1 << uptime_decorator) | (1 << level_decorator) | (1 << tags_decorator); The internal representation of _decorations_buffer most likely looks as follows. ![Screen Shot 2021-05-04 at 1 11 12 PM](https://user-images.githubusercontent.com/2386768/117063851-424b2100-acda-11eb-8b72-b649a79b5152.png) uptime | lvl(optimized out) | tags 2.582s '\0' '\0' codestrings '\0' [followed by garbage bytes] I think it's a good idea to copy what we need. My copy constructor actually just copys 20bytes instead of 256 bytes. LogDecorations::LogDecorations(const LogDecorations& o) : _level(o._level), _tagset(o._tagset) { size_t sz = 0; for (int i = 0; i < LogDecorators::Count; ++i) { if (o._decoration_offset[i] != NULL) { sz += strlen(o._decoration_offset[i]) + 1; } } // safe to call with sz = 0 memcpy(_decorations_buffer, o._decorations_buffer, sz); for (int i = 0; i < LogDecorators::Count; ++i) { if (o._decoration_offset[i] != NULL) { _decoration_offset[i] = (o._decoration_offset[i] - o._decorations_buffer) + _decorations_buffer; } else { _decoration_offset[i] = NULL; } } } Can we that resolve copy ctor of logDecoration in this JBS? I think we can split this from that PR, which has been quite big. I can try your approach and see how much performance hit on average. src/hotspot/share/logging/logDecorations.hpp line 43: > 41: typedef uint8_t offset_t; > 42: static const offset_t invalid_offset = DecorationsBufferSize - 1; > 43: offset_t _decoration_offset[LogDecorators::Count]; This is less flexible than before. the type uint8_t limits the size of _decorations_buffer is lesser than 256. it's impossible to stretch _decorations_buffer. Further, we should avoid implicit assumption between DecorationsBufferSize and uint8_t. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From dholmes at openjdk.java.net Tue May 4 22:28:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 22:28:54 GMT Subject: RFR: 8255566: Add size validation when parsing values from VersionProps In-Reply-To: References: Message-ID: On Tue, 4 May 2021 00:38:54 GMT, David Holmes wrote: > java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. > > Testing: tiers 1-3 > > Thanks, > David Thanks Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/3848 From dholmes at openjdk.java.net Tue May 4 22:28:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 22:28:54 GMT Subject: Integrated: 8255566: Add size validation when parsing values from VersionProps In-Reply-To: References: Message-ID: On Tue, 4 May 2021 00:38:54 GMT, David Holmes wrote: > java.lang.VersionProps defines a number of JDK version properties that are read by the VM and stored in JDK_Version or VM_Version. These values are read into fixed size buffers with no guarantee that the value will actually fit. The proposed solution is to get rid of the fixed size buffers, allocate initially into the thread's resource area then make a permanent copy using os::strdup. > > Testing: tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: d2827994 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/d2827994f8a55f5af300baeb1e588ee140f4e78f Stats: 38 lines in 2 files changed: 6 ins; 15 del; 17 mod 8255566: Add size validation when parsing values from VersionProps Reviewed-by: rehn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3848 From xliu at openjdk.java.net Tue May 4 23:45:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 4 May 2021 23:45:49 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight hi, Thomas, I compare yours and mine using `java -Xlog:async -Xlog:'all=trace:file=hotspot-async.log:uptime,tid,l,tg:filecount=0' --version`. here is the performance comparison. baseline is synchronized log outputs. custom copy ctor is what I am using in PR#3135. | | | wall-time(ms) | | |---|-------------------|---------------|---| | 1 | baseline | 96.942 | | | 2 | custom copy ctor | 84.008 | | | 3 | default copy ctor | 84.226 | | | | | | | I acknowledge that copying _decorations_buffer as need is not necessary. use default copy ctor is good enough. thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From dholmes at openjdk.java.net Tue May 4 23:55:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 23:55:50 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Sorry for the delay in noticing this PR! Fix looks good. One nit on variable naming below. Thanks, David src/hotspot/share/logging/logConfiguration.cpp line 430: > 428: ConfigurationLock cl; > 429: size_t idx; > 430: bool is_added = false; Nit: `was_added` (or even just `added`) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From xliu at openjdk.java.net Wed May 5 00:07:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 5 May 2021 00:07:49 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight Marked as reviewed by xliu (no project role). ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From xliu at openjdk.java.net Wed May 5 00:07:50 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 5 May 2021 00:07:50 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 19:57:45 GMT, Xin Liu wrote: >> In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. >> >> Better would be to use a numerical index array of offset values, which could be safely copied. >> >> And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. >> >> The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. >> >> Testing: >> - manually jtreg runtime/logging >> - manually gtests >> - Will run more tests tonight > > src/hotspot/share/logging/logDecorations.hpp line 43: > >> 41: typedef uint8_t offset_t; >> 42: static const offset_t invalid_offset = DecorationsBufferSize - 1; >> 43: offset_t _decoration_offset[LogDecorators::Count]; > > This is less flexible than before. the type uint8_t limits the size of _decorations_buffer is lesser than 256. it's impossible to stretch _decorations_buffer. Further, we should avoid implicit assumption between DecorationsBufferSize and uint8_t. I see that you have a statement. It does check offset_t is wide enough to represent DecorationsBufferSize. static const offset_t invalid_offset = DecorationsBufferSize - 1; `` ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From dholmes at openjdk.java.net Wed May 5 00:19:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 5 May 2021 00:19:49 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Hi Coleen, Seems reasonable. Nice simplification too! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From sspitsyn at openjdk.java.net Wed May 5 01:09:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 01:09:54 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Hi Coleen, This looks good to me in general. I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line: `4005 if (emcp_method_count != 0 && obsolete_method_count != 0 &&` Suppose, the emcp_method_count is equal to 0. Then do we really want to skip marking all the methods of this InstanceKlass as obsolete? Most likely, I'm missing something. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From stuefe at openjdk.java.net Wed May 5 03:34:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 03:34:13 GMT Subject: RFR: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error Message-ID: On AIX, in os::attempt_reserve_memory_at(), if the user specified a wish address too close to the BRK segment, we silently ignore the wish address and just map anywhere. This is not the right behavior since the normal behavior when failing to map to a wish address is to return NULL (see JDK-8266419). Therefore we should return NULL in these cases instead. This is a day zero bug. ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3859/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3859&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266506 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3859.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3859/head:pull/3859 PR: https://git.openjdk.java.net/jdk/pull/3859 From stuefe at openjdk.java.net Wed May 5 03:36:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 03:36:16 GMT Subject: RFR: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address Message-ID: On AIX, in mmap() mode, if the mmap call succeeds but not at the requested address, the mapping should be unmapped and the operation should count as error - like it is done on all other platforms. (AFAICS this is a day zero bug in our port - mmap mode is seldomly used). Tested: Nightlies at SAP with and without 4K pages. ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3834/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3834&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266419 Stats: 15 lines in 1 file changed: 5 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3834.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3834/head:pull/3834 PR: https://git.openjdk.java.net/jdk/pull/3834 From xliu at openjdk.java.net Wed May 5 06:57:59 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 5 May 2021 06:57:59 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Your bugfix looks good to me. I am not a reviewer. I just happen to work on this file recently. You still need reviewer's approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From stuefe at openjdk.java.net Wed May 5 07:21:10 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 07:21:10 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight Converted back to Draft because I think this can be done much better by splitting decorator resolution phase and printing phase. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From stuefe at openjdk.java.net Wed May 5 08:05:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 08:05:49 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From sspitsyn at openjdk.java.net Wed May 5 09:11:52 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 09:11:52 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From redestad at openjdk.java.net Wed May 5 09:55:54 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 5 May 2021 09:55:54 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind In-Reply-To: References: Message-ID: On Tue, 4 May 2021 01:44:08 GMT, Ioi Lam wrote: >> This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. >> >> Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. >> >> Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. > > src/hotspot/share/interpreter/abstractInterpreter.cpp line 143: > >> 141: // _dsqrt will be selected for both Math::sqrt and StrictMath::sqrt, but the latter >> 142: // is native. Keep treating it like a native method in the interpreter >> 143: case vmIntrinsics::_dsqrt: return m->is_native() ? native : java_lang_math_sqrt; > > Maybe we should add an assert that m must be one of the two methods mentioned by the above comment? Ok. I'll add an assertion that allows for the StrictMath variant to be re-implemented in java ------------- PR: https://git.openjdk.java.net/jdk/pull/3798 From redestad at openjdk.java.net Wed May 5 10:18:16 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 5 May 2021 10:18:16 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v2] In-Reply-To: References: Message-ID: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: assert that vmIntrinsics::_dsqrt are only selected for Math/StrictMath::sqrt ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3798/files - new: https://git.openjdk.java.net/jdk/pull/3798/files/4f7ea902..4e616b33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=00-01 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From mdoerr at openjdk.java.net Wed May 5 10:18:51 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 5 May 2021 10:18:51 GMT Subject: RFR: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error In-Reply-To: References: Message-ID: On Tue, 4 May 2021 15:28:21 GMT, Thomas Stuefe wrote: > On AIX, in os::attempt_reserve_memory_at(), if the user specified a wish address too close to the BRK segment, we silently ignore the wish address and just map anywhere. > > This is not the right behavior since the normal behavior when failing to map to a wish address is to return NULL (see JDK-8266419). Therefore we should return NULL in these cases instead. > > This is a day zero bug. Looks good. Thanks for fixing. You may want to update the trace message "Will attach anywhere.". ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3859 From mdoerr at openjdk.java.net Wed May 5 10:23:50 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 5 May 2021 10:23:50 GMT Subject: RFR: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address In-Reply-To: References: Message-ID: On Mon, 3 May 2021 06:36:15 GMT, Thomas Stuefe wrote: > On AIX, in mmap() mode, if the mmap call succeeds but not at the requested address, the mapping should be unmapped and the operation should count as error - like it is done on all other platforms. > > (AFAICS this is a day zero bug in our port - mmap mode is seldomly used). > > Tested: Nightlies at SAP with and without 4K pages. Thanks for fixing. Looks good. Maybe the trace message should mention that we're unmapping it again? ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3834 From mdoerr at openjdk.java.net Wed May 5 10:27:49 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 5 May 2021 10:27:49 GMT Subject: RFR: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping In-Reply-To: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> References: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> Message-ID: On Wed, 28 Apr 2021 15:35:47 GMT, Thomas Stuefe wrote: > In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). > > When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. > > However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. > > After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. > > Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). > > This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. > > Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. This looks good. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3765 From stuefe at openjdk.java.net Wed May 5 10:44:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 10:44:05 GMT Subject: RFR: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping In-Reply-To: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> References: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> Message-ID: On Wed, 28 Apr 2021 15:35:47 GMT, Thomas Stuefe wrote: > In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). > > When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. > > However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. > > After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. > > Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). > > This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. > > Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. Danke, Martin! ------------- PR: https://git.openjdk.java.net/jdk/pull/3765 From mli at openjdk.java.net Wed May 5 10:48:55 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 5 May 2021 10:48:55 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com> <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com> <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com> Message-ID: On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> improve jcmd GC.class_histogram to support parallel > > For jmap -histo we have: > > parallel= parallel threads number for heap iteration: > parallel=0 default behavior, use predefined number of threads > parallel=1 disable parallel heap iteration > parallel= use N threads for parallel heap iteration > > It's a bit inconsistent here in that it says , , and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has: > > Options: (options must be specified using the or = syntax) > -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false) > -gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1) > > The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or , or anything like that: > > "Number of parallel threads to use for heap inspection." > "0 (the default) means let the VM determine the number of threads to use. " > "1 means use one thread (disable parallelism). " > "For any other value the VM will try to use the specified number of threads, but might use fewer." > > I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given. @plummercj @sspitsyn Kindly reminder. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From stuefe at openjdk.java.net Wed May 5 11:52:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:52:51 GMT Subject: RFR: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping In-Reply-To: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> References: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> Message-ID: <18lw6YYFEqZMQGJiFGVHuKDLOnX3DGpRlp2NXfBzjLE=.bfb8fca6-f44d-45a2-999c-bcb667e49e1c@github.com> On Wed, 28 Apr 2021 15:35:47 GMT, Thomas Stuefe wrote: > In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). > > When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. > > However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. > > After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. > > Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). > > This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. > > Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. Note that since we don't have that many AIX reviewers, and this only concerns AIX code, I go ahead and push. Its our port anyway, if something breaks we will have to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3765 From stuefe at openjdk.java.net Wed May 5 11:52:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:52:51 GMT Subject: Integrated: JDK-8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping In-Reply-To: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> References: <6QFbE-u_pwoMb8HWXgy60whGZUl7ptGyqLsMeXZf84Y=.cd9af040-414d-4823-8002-05045688d9b4@github.com> Message-ID: On Wed, 28 Apr 2021 15:35:47 GMT, Thomas Stuefe wrote: > In os_aix.cpp we keep book about for reserved address ranges since we need to keep information about which API (mmap or shmat) had been used for this range. (code hint: see vmembk_(add|remove|find)). > > When releasing memory via os::release_memory, we remove those ranges from the internal bookkeeping. > > However, for mmap() the release may be partial. In that case the internal bookkeeping is not updated correctly: we just remove the record for the whole original address range. > > After that operation, the remainder address range is still mapped from the point of the VM, but the bookkeeping is lost and subsequent calls to os::release_memory or os::commit/uncommit_memory for this range will run into a guarantee. > > Partial releases can happen e.g. when, in the process of running os::reserve_memory_aligned(), the extra-aligned pages are unmapped. This is of more concern now with the new Metaspace, since we now reserve with larger alignments (4G+). > > This problem was hidden by the fact that we typically run in 64K paged mode where we use SysV shared memory; but if AME is enabled on AIX, 64K pages are disabled, and the VM falls back to 4K pages and using mmap, and runs into this bug. > > Edit: Tested on AIX machines with and without AME activated, solves the problems. All SAP nightlies ran, no problems caused by this patch. This pull request has now been integrated. Changeset: 250b45a5 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/250b45a510114d00059199701e626e3a63fc1fe7 Stats: 25 lines in 1 file changed: 19 ins; 1 del; 5 mod 8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping Reviewed-by: mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/3765 From rehn at openjdk.java.net Wed May 5 11:54:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 5 May 2021 11:54:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked Message-ID: Please consider this change which removes the manual transitions to blocked. This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. The object monitor code could be straight forward changed to use this instead of manual transitions. Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. That made it possible to careful use ThreadInVMfromNative in raw monitors. I also remove the early CAS in raw_enter. We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) Passes t1-t7 and manual stressing relevant test groups. ------------- Commit messages: - Removed manual transitions Changes: https://git.openjdk.java.net/jdk/pull/3875/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265753 Stats: 327 lines in 8 files changed: 122 ins; 155 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From stuefe at openjdk.java.net Wed May 5 11:59:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:59:16 GMT Subject: RFR: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address [v2] In-Reply-To: References: Message-ID: <9K9cAtGMTXAUWJDHLJgefNBZwbBUw3QWyL6iEvv-g58=.e7c400e1-039d-4177-82c0-d717591414a3@github.com> > On AIX, in mmap() mode, if the mmap call succeeds but not at the requested address, the mapping should be unmapped and the operation should count as error - like it is done on all other platforms. > > (AFAICS this is a day zero bug in our port - mmap mode is seldomly used). > > Tested: Nightlies at SAP with and without 4K pages. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Modify log message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3834/files - new: https://git.openjdk.java.net/jdk/pull/3834/files/138fae89..074e73d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3834&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3834&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3834.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3834/head:pull/3834 PR: https://git.openjdk.java.net/jdk/pull/3834 From stuefe at openjdk.java.net Wed May 5 11:59:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:59:17 GMT Subject: RFR: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:20:48 GMT, Martin Doerr wrote: > Thanks for fixing. Looks good. Maybe the trace message should mention that we're unmapping it again? Thanks Martin. You are right, I will update the log message. ------------- PR: https://git.openjdk.java.net/jdk/pull/3834 From stuefe at openjdk.java.net Wed May 5 11:59:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:59:17 GMT Subject: RFR: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address In-Reply-To: References: Message-ID: On Mon, 3 May 2021 06:36:15 GMT, Thomas Stuefe wrote: > On AIX, in mmap() mode, if the mmap call succeeds but not at the requested address, the mapping should be unmapped and the operation should count as error - like it is done on all other platforms. > > (AFAICS this is a day zero bug in our port - mmap mode is seldomly used). > > Tested: Nightlies at SAP with and without 4K pages. Note that since we don't have that many AIX reviewers, and this only concerns AIX code, I go ahead and push. It is our port anyway, if something breaks we will have to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3834 From stuefe at openjdk.java.net Wed May 5 11:59:18 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 11:59:18 GMT Subject: Integrated: JDK-8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address In-Reply-To: References: Message-ID: On Mon, 3 May 2021 06:36:15 GMT, Thomas Stuefe wrote: > On AIX, in mmap() mode, if the mmap call succeeds but not at the requested address, the mapping should be unmapped and the operation should count as error - like it is done on all other platforms. > > (AFAICS this is a day zero bug in our port - mmap mode is seldomly used). > > Tested: Nightlies at SAP with and without 4K pages. This pull request has now been integrated. Changeset: 02cdd6eb Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/02cdd6eb6d1e4bc99f8f34786e92c33123e50482 Stats: 15 lines in 1 file changed: 5 ins; 8 del; 2 mod 8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address Reviewed-by: mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/3834 From stuefe at openjdk.java.net Wed May 5 12:01:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 12:01:23 GMT Subject: RFR: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error [v2] In-Reply-To: References: Message-ID: > On AIX, in os::attempt_reserve_memory_at(), if the user specified a wish address too close to the BRK segment, we silently ignore the wish address and just map anywhere. > > This is not the right behavior since the normal behavior when failing to map to a wish address is to return NULL (see JDK-8266419). Therefore we should return NULL in these cases instead. > > This is a day zero bug. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Modify log message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3859/files - new: https://git.openjdk.java.net/jdk/pull/3859/files/6e65b6b5..a5297796 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3859&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3859&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3859.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3859/head:pull/3859 PR: https://git.openjdk.java.net/jdk/pull/3859 From stuefe at openjdk.java.net Wed May 5 12:01:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 12:01:23 GMT Subject: RFR: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:15:29 GMT, Martin Doerr wrote: > Looks good. Thanks for fixing. You may want to update the trace message "Will attach anywhere.". Again you are right. I will fix before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3859 From stuefe at openjdk.java.net Wed May 5 12:01:24 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 12:01:24 GMT Subject: RFR: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error In-Reply-To: References: Message-ID: On Tue, 4 May 2021 15:28:21 GMT, Thomas Stuefe wrote: > On AIX, in os::attempt_reserve_memory_at(), if the user specified a wish address too close to the BRK segment, we silently ignore the wish address and just map anywhere. > > This is not the right behavior since the normal behavior when failing to map to a wish address is to return NULL (see JDK-8266419). Therefore we should return NULL in these cases instead. > > This is a day zero bug. Note that since we don't have that many AIX reviewers, and this only concerns AIX code, I go ahead and push. It is our port anyway, if something breaks we will have to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3859 From stuefe at openjdk.java.net Wed May 5 12:01:24 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 12:01:24 GMT Subject: Integrated: JDK-8266506: [aix] Treat mapping attempt too close to BRK as a mapping error In-Reply-To: References: Message-ID: <90KulKhz3U4ArgieHncoOYMf1u1ZZP-Ek8w9ZxXzygQ=.5e7495f8-e11a-4e48-8fa7-0d8e85b16a18@github.com> On Tue, 4 May 2021 15:28:21 GMT, Thomas Stuefe wrote: > On AIX, in os::attempt_reserve_memory_at(), if the user specified a wish address too close to the BRK segment, we silently ignore the wish address and just map anywhere. > > This is not the right behavior since the normal behavior when failing to map to a wish address is to return NULL (see JDK-8266419). Therefore we should return NULL in these cases instead. > > This is a day zero bug. This pull request has now been integrated. Changeset: 0ac84d18 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/0ac84d18133857a75769e2bb3ac2c2d2f9508191 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8266506: [aix] Treat mapping attempt too close to BRK as a mapping error Reviewed-by: mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/3859 From vlivanov at openjdk.java.net Wed May 5 12:51:08 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 5 May 2021 12:51:08 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed Message-ID: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Some test cleanups: - removed all `@KnownFailure` - narrowed expected error types in some cases - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent - some other minor cleanups Testing: - [x] defmeth tests - [x] hs-tier5 - hs-tier6 (include defmeth tests) ------------- Commit messages: - Misc cleanups - PrivateMethodsTest - Constructor call support - Refactor vm.runtime.defmeth tests Changes: https://git.openjdk.java.net/jdk/pull/3879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3879&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8208237 Stats: 663 lines in 20 files changed: 132 ins; 356 del; 175 mod Patch: https://git.openjdk.java.net/jdk/pull/3879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3879/head:pull/3879 PR: https://git.openjdk.java.net/jdk/pull/3879 From hseigel at openjdk.java.net Wed May 5 13:00:18 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 5 May 2021 13:00:18 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes Message-ID: Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. The fix 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: - 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes Changes: https://git.openjdk.java.net/jdk/pull/3882/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3882&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266496 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3882/head:pull/3882 PR: https://git.openjdk.java.net/jdk/pull/3882 From coleenp at openjdk.java.net Wed May 5 13:02:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> References: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> Message-ID: On Wed, 5 May 2021 01:07:13 GMT, Serguei Spitsyn wrote: >> Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. >> >> Tested with tier1-6, tiers 7,8 are running and 98% passing. > > Hi Coleen, > > This looks good to me in general. > I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line: > `4005 if (emcp_method_count != 0 && obsolete_method_count != 0 &&` > > Suppose, the emcp_method_count is equal to 0. > Then do we really want to skip marking all the methods of this InstanceKlass as obsolete? > Most likely, I'm missing something. > > Thanks, > Serguei @sspitsyn I think you're right here. If all the newly old methods are obsolete, then we should mark all the methods in the previous versions as obsolete and not skip this. I'll file an issue to investigate this because it's always been this way (and could use a test also). It's too risky to change here. Thanks for the code review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Wed May 5 13:02:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:53 GMT Subject: Integrated: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. This pull request has now been integrated. Changeset: a05e8e24 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/a05e8e24224b047584c3a273fa7b4fef66798dd6 Stats: 78 lines in 4 files changed: 9 ins; 64 del; 5 mod 8266497: Remove unnecessary EMCP liveness indication Reviewed-by: iklam, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Wed May 5 13:02:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks for the code review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From dholmes at openjdk.java.net Wed May 5 13:30:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 5 May 2021 13:30:52 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes In-Reply-To: References: Message-ID: On Wed, 5 May 2021 12:49:20 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. > > The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Hi Harold, Fix seems fine - certainly good enough for whitebox purposes. Does the test need to generate the classfile? can't you just define a class in the same source file and then read the class file from disk? Whenever I see asm being used I wonder what it is about the class that prevented it being written in Java. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3882 From hseigel at openjdk.java.net Wed May 5 13:43:50 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 5 May 2021 13:43:50 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes In-Reply-To: References: Message-ID: On Wed, 5 May 2021 12:49:20 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. > > The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Hi David, Thanks for reviewing this. The test doesn't need to use asm. It could load the class from disk as you suggested, or even use InMemoryJavaCompiler. Please let me know if I should change the test. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3882 From minqi at openjdk.java.net Wed May 5 16:17:15 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 16:17:15 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens Message-ID: Hi, Please review When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. The newly added test case skipped testing on Windows since File operation result is not same as on Linux. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8265465: jcmd VM.cds should keep already dumped archive when exception happens Changes: https://git.openjdk.java.net/jdk/pull/3886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265465 Stats: 188 lines in 3 files changed: 158 ins; 5 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Wed May 5 16:34:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 16:34:20 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: JCmdTestFileSecurity.java should be excluded from dynamic test group ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/9ba99117..b420da7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From iklam at openjdk.java.net Wed May 5 18:37:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 5 May 2021 18:37:54 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: References: Message-ID: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> On Wed, 5 May 2021 16:34:20 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > JCmdTestFileSecurity.java should be excluded from dynamic test group Changes requested by iklam (Reviewer). src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: > 282: > 283: String tempFileName = getArchiveFileName(archiveFileName); > 284: File tempArchiveFile = new File(tempFileName); I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` String tempArchiveFileName = archiveFileName + ".tmp"; src/java.base/share/classes/jdk/internal/misc/CDS.java line 288: > 286: if (isStatic) { > 287: String listFileName = tempFileName + ".classlist"; > 288: File listFile = new File(listFileName); There's no need to use tempFileName for the classlist. The list file is always deleted after the dump has finished. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 37: > 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox > 36: * @run main/othervm/timeout=480 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI JCmdTestFileSecurity > 37: */ "Security" is usually used for Java language security. I think it's better to call this test JCmdTestFileSafety. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 63: > 61: test(localFileName, pid, noBoot, EXPECT_PASS); > 62: File targetFile = CDSTestUtils.getOutputDirAsFile(); > 63: targetFile.setWritable(false); getOutputDirAsFile returns the current directory. Other test code may write to this directory. I think it's better to specify: localFileName = "subdir" + File.separator() + "MyStaticDump.jsa"; and set `subdir` to be non-writeable. Also, the local variable should be `targetDir` instead of `targetFile`. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 92: > 90: public static void main(String... args) throws Exception { > 91: if (Platform.isWindows()) { > 92: // ON windows, File operation resulted difference from other OS. Could you explain what the differences are? ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Wed May 5 18:47:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 5 May 2021 18:47:54 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> References: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> Message-ID: <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> On Wed, 5 May 2021 18:20:43 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> JCmdTestFileSecurity.java should be excluded from dynamic test group > > src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: > >> 282: >> 283: String tempFileName = getArchiveFileName(archiveFileName); >> 284: File tempArchiveFile = new File(tempFileName); > > I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` > > > String tempArchiveFileName = archiveFileName + ".tmp"; getArchiveFileName also operates on create/delete temp file, so if that fails, throw exception back to caller. Do you think the logic should be kept? > src/java.base/share/classes/jdk/internal/misc/CDS.java line 288: > >> 286: if (isStatic) { >> 287: String listFileName = tempFileName + ".classlist"; >> 288: File listFile = new File(listFileName); > > There's no need to use tempFileName for the classlist. The list file is always deleted after the dump has finished. Yes, will revert it back. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 37: > >> 35: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox >> 36: * @run main/othervm/timeout=480 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI JCmdTestFileSecurity >> 37: */ > > "Security" is usually used for Java language security. I think it's better to call this test JCmdTestFileSafety. Sure. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 63: > >> 61: test(localFileName, pid, noBoot, EXPECT_PASS); >> 62: File targetFile = CDSTestUtils.getOutputDirAsFile(); >> 63: targetFile.setWritable(false); > > getOutputDirAsFile returns the current directory. Other test code may write to this directory. I think it's better to specify: > > > localFileName = "subdir" + File.separator() + "MyStaticDump.jsa"; > > > and set `subdir` to be non-writeable. > > Also, the local variable should be `targetDir` instead of `targetFile`. Will try this, not sure if the subdir and the file can be created with current code. May be some extra code needed. Thanks for the review! > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSecurity.java line 92: > >> 90: public static void main(String... args) throws Exception { >> 91: if (Platform.isWindows()) { >> 92: // ON windows, File operation resulted difference from other OS. > > Could you explain what the differences are? Will add detail explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From hseigel at openjdk.java.net Wed May 5 18:55:16 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 5 May 2021 18:55:16 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: > Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. > > The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Update test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3882/files - new: https://git.openjdk.java.net/jdk/pull/3882/files/c5e96925..36739c57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3882&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3882&range=00-01 Stats: 45 lines in 1 file changed: 9 ins; 24 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3882/head:pull/3882 PR: https://git.openjdk.java.net/jdk/pull/3882 From iklam at openjdk.java.net Wed May 5 19:27:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 5 May 2021 19:27:52 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v2] In-Reply-To: <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> References: <71lDNVjApEHqSRtBg1ysBe1KtxeLzTrBCf4YML4wD6g=.d3a1defb-f9d2-41bb-8b9d-00f60c9db8c9@github.com> <8aAiaSoL9zISBD9jyPEg_z9TWXj1ds6Gl0nJ9NhmCuc=.179dfd00-88fb-4080-b186-30d9179f5c99@github.com> Message-ID: On Wed, 5 May 2021 18:42:20 GMT, Yumin Qi wrote: >> src/java.base/share/classes/jdk/internal/misc/CDS.java line 284: >> >>> 282: >>> 283: String tempFileName = getArchiveFileName(archiveFileName); >>> 284: File tempArchiveFile = new File(tempFileName); >> >> I think the logic is too complicated. We can always write the archive to a temp file, and then rename it to the actual file. Also, to be consistent with the other variables, it should be `tempArchiveFileName` >> >> >> String tempArchiveFileName = archiveFileName + ".tmp"; > > getArchiveFileName also operates on create/delete temp file, so if that fails, throw exception back to caller. Do you think the logic should be kept? How about: File tempArchiveFile = new File(tempArchiveFileName); tempArchiveFile.createNewFile(); // will throw exception if we cannot write to the directory. tempArchiveFile.delete(); ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From xliu at openjdk.java.net Wed May 5 19:35:52 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 5 May 2021 19:35:52 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight I read this patch and PR#3874. IMHO, I don't think PR#3874 is over this patch in terms of "makes the code easier to understand and read." The change is obviously bigger(+238 ?117) than this one. Is it worth it? To me, the only critical drawback of storing resolved c-string is i18n. As a matter of fact, The unified logging doesn't put i18n in consideration, so it is not an issue. A universal buffer seems cleaner than scatter fields. Reducing size(from 368 -> 56 bytes on Linux x64) is appealing, but it actually has very limited impact on real performance. I am not a reviewer. Those are all my personal opinions. Take it as a grain of salt. I can go either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From darcy at openjdk.java.net Wed May 5 21:03:18 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 5 May 2021 21:03:18 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 Message-ID: Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. JEP 306 is considering the following changes to the JVMS: 1) Require "strict" floating-point evaluation in all circumstances. 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. ------------- Commit messages: - 8266530: HotSpot changes for JEP 306 Changes: https://git.openjdk.java.net/jdk/pull/3891/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266530 Stats: 416 lines in 6 files changed: 414 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From forax at univ-mlv.fr Wed May 5 21:27:06 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 5 May 2021 23:27:06 +0200 (CEST) Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: Message-ID: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Joe Darcy" > ?: "hotspot-runtime-dev" > Envoy?: Mercredi 5 Mai 2021 23:03:18 > Objet: RFR: 8266530: HotSpot changes for JEP 306 > Please review these VM changes in support of JEP 306: Restore Always-Strict > Floating-Point Semantics. > with my ASM hat, > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit > position back to undefined for methods. For class file versions, 46 through, > ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not > needed to indicate this anymore. There are a few mandated modifier checks when > ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. > These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version > 60 and does not trigger an error or exception for version 61. (As an undefined > bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under > https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither > relies on the other: > * javac will not output class files which expose the difference in class parsing > behavior; the ACC_STRICT modifier will not be set in any version 61 class file > emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes > are needed to support strict evaluation. I would prefer the VM to reject ACC_STRICT (if version >= 61) instead of ignoring it. Given that we now have a mono-repo, there is no flag day issue. The problem of ignoring it is that classfile producer other than javac will not be updated for v61 since the maintainer of the tool may be not aware of this change so every tools will update at some point some sooner, some later. Given that ASM is based on Visitors from different libraries that can be plugged one with the other, for users of those libraries they may see side effect of one library being updated and another not being updated yet. By example, the ACC_STRICT on methods will be removed but not the one on classes or vice-versa. If possible, I would prefer ACC_STRICT to be banned instead of being ignored, for version >= 51. R?mi > > ------------- > > Commit messages: > - 8266530: HotSpot changes for JEP 306 > > Changes: https://git.openjdk.java.net/jdk/pull/3891/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8266530 > Stats: 416 lines in 6 files changed: 414 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/3891.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 > > PR: https://git.openjdk.java.net/jdk/pull/3891 From joe.darcy at oracle.com Wed May 5 21:51:20 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 5 May 2021 14:51:20 -0700 Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> Message-ID: <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> On 5/5/2021 2:27 PM, Remi Forax wrote: > ----- Mail original ----- >> De: "Joe Darcy" >> ?: "hotspot-runtime-dev" >> Envoy?: Mercredi 5 Mai 2021 23:03:18 >> Objet: RFR: 8266530: HotSpot changes for JEP 306 >> Please review these VM changes in support of JEP 306: Restore Always-Strict >> Floating-Point Semantics. >> > with my ASM hat, > >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit >> position back to undefined for methods. For class file versions, 46 through, >> ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not >> needed to indicate this anymore. There are a few mandated modifier checks when >> ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. >> These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version >> 60 and does not trigger an error or exception for version 61. (As an undefined >> bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under >> https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither >> relies on the other: >> * javac will not output class files which expose the difference in class parsing >> behavior; the ACC_STRICT modifier will not be set in any version 61 class file >> emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes >> are needed to support strict evaluation. > I would prefer the VM to reject ACC_STRICT (if version >= 61) instead of ignoring it. > Given that we now have a mono-repo, there is no flag day issue. That is true from a JDK development perspective. However, the general JVMS guidance is: "All bits of the access_flags item not assigned in Table 4.6-A are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations. " We haven't had a bit position go through undefined -> defined -> undefined before so there isn't direct precedence on how the situation should be treated. > > The problem of ignoring it is that classfile producer other than javac will not be updated for v61 since the maintainer of the tool may be not aware of this change so every tools will update at some point some sooner, some later. Given that ASM is based on Visitors from different libraries that can be plugged one with the other, for users of those libraries they may see side effect of one library being updated and another not being updated yet. By example, the ACC_STRICT on methods will be removed but not the one on classes or vice-versa. As a reminder, at the VM level strictness only exists as ACC_STRICT on methods; there is no type-level strict modifiers in the VM, unlike in the Java language. -Joe From coleenp at openjdk.java.net Wed May 5 22:13:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 22:13:56 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:55:16 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. >> >> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Update test LGTM! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3882 From mseledtsov at openjdk.java.net Wed May 5 22:17:52 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Wed, 5 May 2021 22:17:52 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:55:16 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. >> >> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Update test Change looks good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/3882 From lfoltan at openjdk.java.net Wed May 5 22:21:52 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 5 May 2021 22:21:52 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:55:16 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. >> >> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Update test Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3882 From dholmes at openjdk.java.net Wed May 5 22:28:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 5 May 2021 22:28:50 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:55:16 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. >> >> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Update test No need to change test. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3882 From forax at univ-mlv.fr Wed May 5 23:57:00 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 6 May 2021 01:57:00 +0200 (CEST) Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> Message-ID: <1570590060.24715.1620259020879.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "joe darcy" > ?: "Remi Forax" , "Joe Darcy" > Cc: "hotspot-runtime-dev" > Envoy?: Mercredi 5 Mai 2021 23:51:20 > Objet: Re: RFR: 8266530: HotSpot changes for JEP 306 > On 5/5/2021 2:27 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Joe Darcy" >>> ?: "hotspot-runtime-dev" >>> Envoy?: Mercredi 5 Mai 2021 23:03:18 >>> Objet: RFR: 8266530: HotSpot changes for JEP 306 >>> Please review these VM changes in support of JEP 306: Restore Always-Strict >>> Floating-Point Semantics. >>> >> with my ASM hat, >> >>> JEP 306 is considering the following changes to the JVMS: >>> >>> 1) Require "strict" floating-point evaluation in all circumstances. >>> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit >>> position back to undefined for methods. For class file versions, 46 through, >>> ACC_STRICT would remain a defined modifier. >>> >>> Since all floating-point evaluation is done strictly, a modifier bit is not >>> needed to indicate this anymore. There are a few mandated modifier checks when >>> ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. >>> These checks in classFileParser are now conditional on the class file version. >>> >>> The tests verify "abstract strictfp" triggers a ClassFormatError for version >>> 60 and does not trigger an error or exception for version 61. (As an undefined >>> bit in version 61, the VM is supposed to ignore it.) >>> >>> FYI, the javac and core libs portions of JEP 306 are out for review under >>> https://github.com/openjdk/jdk/pull/3831. >>> >>> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither >>> relies on the other: >>> * javac will not output class files which expose the difference in class parsing >>> behavior; the ACC_STRICT modifier will not be set in any version 61 class file >>> emitted by javac. >>> * since HotSpot already does all floating-point evaluation strictly, no changes >>> are needed to support strict evaluation. >> I would prefer the VM to reject ACC_STRICT (if version >= 61) instead of >> ignoring it. >> Given that we now have a mono-repo, there is no flag day issue. > > That is true from a JDK development perspective. However, the general > JVMS guidance is: > > "All bits of the access_flags item not assigned in Table 4.6-A are > reserved for future use. They should be set to zero in generated class > files and should be ignored by Java Virtual Machine implementations. " > > We haven't had a bit position go through undefined -> defined -> > undefined before so there isn't direct precedence on how the situation > should be treated. Given that its value 0x800 is not used on other members, it can be reused to indicate something on class/field/method. So we may want to recycle it undefined -> defined -> undefined -> defined > > >> >> The problem of ignoring it is that classfile producer other than javac will not >> be updated for v61 since the maintainer of the tool may be not aware of this >> change so every tools will update at some point some sooner, some later. Given >> that ASM is based on Visitors from different libraries that can be plugged one >> with the other, for users of those libraries they may see side effect of one >> library being updated and another not being updated yet. By example, the >> ACC_STRICT on methods will be removed but not the one on classes or >> vice-versa. > > As a reminder, at the VM level strictness only exists as ACC_STRICT on > methods; there is no type-level strict modifiers in the VM, unlike in > the Java language. Ah, thanks, i've forgotten that. So the issue will be more with visitors that introduce special methods like constructors or a static block. Github depressingly found 34,729 snippet of code containing ACC_STRICT (the corresponding ASM flag) [1], I hope that most of the occurrences are in internal visitors and not in public reuseable ones :( > > -Joe R?mi [1] https://github.com/search?l=Java&q=ACC_STRICT&type=Code From sspitsyn at openjdk.java.net Thu May 6 00:09:50 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 6 May 2021 00:09:50 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks, Coleen! I agree, it is better to file a new bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From joe.darcy at oracle.com Thu May 6 00:14:05 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 5 May 2021 17:14:05 -0700 Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: <1570590060.24715.1620259020879.JavaMail.zimbra@u-pem.fr> References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> <1570590060.24715.1620259020879.JavaMail.zimbra@u-pem.fr> Message-ID: On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "joe darcy" >> ?: "Remi Forax" , "Joe Darcy" >> Cc: "hotspot-runtime-dev" >> Envoy?: Mercredi 5 Mai 2021 23:51:20 >> Objet: Re: RFR: 8266530: HotSpot changes for JEP 306 >> On 5/5/2021 2:27 PM, Remi Forax wrote: >>> ----- Mail original ----- >>>> De: "Joe Darcy" >>>> ?: "hotspot-runtime-dev" >>>> Envoy?: Mercredi 5 Mai 2021 23:03:18 >>>> Objet: RFR: 8266530: HotSpot changes for JEP 306 >>>> Please review these VM changes in support of JEP 306: Restore Always-Strict >>>> Floating-Point Semantics. >>>> >>> with my ASM hat, >>> >>>> JEP 306 is considering the following changes to the JVMS: >>>> >>>> 1) Require "strict" floating-point evaluation in all circumstances. >>>> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit >>>> position back to undefined for methods. For class file versions, 46 through, >>>> ACC_STRICT would remain a defined modifier. >>>> >>>> Since all floating-point evaluation is done strictly, a modifier bit is not >>>> needed to indicate this anymore. There are a few mandated modifier checks when >>>> ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. >>>> These checks in classFileParser are now conditional on the class file version. >>>> >>>> The tests verify "abstract strictfp" triggers a ClassFormatError for version >>>> 60 and does not trigger an error or exception for version 61. (As an undefined >>>> bit in version 61, the VM is supposed to ignore it.) >>>> >>>> FYI, the javac and core libs portions of JEP 306 are out for review under >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/3831__;!!GqivPVa7Brio!MAWcvmVSAYuu0lSA6QkqCKenK94TXTIv8klSIlodHn7whAL3J-R3pnc1U9rFKZqw$ . >>>> >>>> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither >>>> relies on the other: >>>> * javac will not output class files which expose the difference in class parsing >>>> behavior; the ACC_STRICT modifier will not be set in any version 61 class file >>>> emitted by javac. >>>> * since HotSpot already does all floating-point evaluation strictly, no changes >>>> are needed to support strict evaluation. >>> I would prefer the VM to reject ACC_STRICT (if version >= 61) instead of >>> ignoring it. >>> Given that we now have a mono-repo, there is no flag day issue. >> That is true from a JDK development perspective. However, the general >> JVMS guidance is: >> >> "All bits of the access_flags item not assigned in Table 4.6-A are >> reserved for future use. They should be set to zero in generated class >> files and should be ignored by Java Virtual Machine implementations. " >> >> We haven't had a bit position go through undefined -> defined -> >> undefined before so there isn't direct precedence on how the situation >> should be treated. > Given that its value 0x800 is not used on other members, it can be reused to indicate something on class/field/method. > So we may want to recycle it > undefined -> defined -> undefined -> defined Yes; the intention of undefining it now is to allow the possibility of the flag position being assigned to another purpose in the future for later class file versions. -Joe From whuang at openjdk.java.net Thu May 6 02:05:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 6 May 2021 02:05:00 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 13:26:22 GMT, Harold Seigel wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix crash problem > > test/hotspot/jtreg/runtime/Nestmates/membership/HostNoNestMember.java line 29: > >> 27: * HostNoNestMember$Member has a class HostNoNestMember as its >> 28: * NestHost, which will trigger an error when resolving . >> 29: */ > > Can you modify the above comment to something such as: > > > * This class was used to produce a jcod file in which the > * NestMembers attribute was modified to make it empty. Class > * HostNoNestMember$Member has class HostNoNestMember as its > * NestHost, which will trigger an error when resolving. > * > * When compiled, this generates a HostNoNestMember class and > * a HostNoNestMember$Menber class. The former class, HostNoNestMember, > * gets overwritten when HostNoNestMember.jcod gets compiled. OK. I will fix that. Thank you. > test/hotspot/jtreg/runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java line 34: > >> 32: * @run main TestNestHostErrorWithMultiThread >> 33: */ >> 34: > > Please add a comment here that HostNoNestMember.jcod must be compiled after HostNoNestMember.java because the class file from the jcod file must replace the HostNoNestMember class file generated from HostNoNestMember.java. Thank you for your review. I will add that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From whuang at openjdk.java.net Thu May 6 02:12:17 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 6 May 2021 02:12:17 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v7] In-Reply-To: References: Message-ID: > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3392/files - new: https://git.openjdk.java.net/jdk/pull/3392/files/adaffaac..ae957908 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3392&range=05-06 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3392.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3392/head:pull/3392 PR: https://git.openjdk.java.net/jdk/pull/3392 From stuefe at openjdk.java.net Thu May 6 04:43:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 04:43:11 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps Message-ID: We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) This patch provides an additional API: `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` alongside the existing `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` and implements the latter using the former. Not much code added. In addition, it adds a regression gtest for these APIs. Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. Testing: GHA, manual gtests, SAP nightlies on all our platforms. Thanks, Thomas ------------- Commit messages: - gtest for os.iso8601_time should use utc - Build fix for Harfbuzz - Merge - start Changes: https://git.openjdk.java.net/jdk/pull/3869/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266536 Stats: 78 lines in 4 files changed: 74 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3869/head:pull/3869 PR: https://git.openjdk.java.net/jdk/pull/3869 From xliu at openjdk.java.net Thu May 6 04:43:12 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 04:43:12 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Wed, 5 May 2021 04:31:57 GMT, Thomas Stuefe wrote: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas The API change looks good to me. I understand that this is prerequisite of your logdecoration change. make sense. I don't understand your change in harfbuzz header. src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 378: > 376: { > 377: machine_index_t (const Iter& it) : it (it) {} > 378: machine_index_t (const machine_index_t& o) : hb_iter_with_fallback_t, typename Iter::item_t>(o), it (o.it) {} is it relevant? I feel it belongs to a separated issue. ------------- Marked as reviewed by xliu (no project role). PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 04:43:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 04:43:13 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:54:42 GMT, Xin Liu wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> Thanks, Thomas > > src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 378: > >> 376: { >> 377: machine_index_t (const Iter& it) : it (it) {} >> 378: machine_index_t (const machine_index_t& o) : hb_iter_with_fallback_t, typename Iter::item_t>(o), it (o.it) {} > > is it relevant? > I feel it belongs to a separated issue. Sorry, forgot to mention. Unrelated harfbuzz build fix for gcc 8 and earlier. Will remove before the final push. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 04:43:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 04:43:13 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Thu, 6 May 2021 04:34:28 GMT, Thomas Stuefe wrote: >> src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 378: >> >>> 376: { >>> 377: machine_index_t (const Iter& it) : it (it) {} >>> 378: machine_index_t (const machine_index_t& o) : hb_iter_with_fallback_t, typename Iter::item_t>(o), it (o.it) {} >> >> is it relevant? >> I feel it belongs to a separated issue. > > Sorry, forgot to mention. Unrelated harfbuzz build fix for gcc 8 and earlier. Will remove before the final push. > The API change looks good to me. I understand that this is prerequisite of your logdecoration change. make sense. > > I don't understand your change in harfbuzz header. Thanks for your review, Xin. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 05:29:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 05:29:53 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight Closing in favor of https://github.com/openjdk/jdk/pull/3874 ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From stuefe at openjdk.java.net Thu May 6 05:29:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 05:29:53 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) In-Reply-To: References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Wed, 5 May 2021 19:32:38 GMT, Xin Liu wrote: > I read this patch and PR #3874. IMHO, I don't think PR #3874 is over this patch in terms of "makes the code easier to understand and read." The change is obviously bigger(+238 ?117) than this one. Is it worth it? Be fair, a lot of those lines is added *tests*, which had not been there before, and added comments, which this code sorely needed. The code size of logDecorations.cpp/hpp is smaller now. I reduced the patch size somewhat further. > > To me, the only critical drawback of storing resolved c-string is i18n. As a matter of fact, unified logging doesn't put i18n into consideration, so it is not an issue. > > A universal buffer seems cleaner than scatter fields, doesn't it? In my opinion no. > Reducing size(from 368 -> 56 bytes on Linux x64) is appealing, but it actually has very limited impact on real performance. Really? It decreases your planned message buffer size, no? > > I am not a reviewer. Those are all my personal opinions. Take it as a grain of salt. I can go either way. I close this PR now in favor of the other one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From stuefe at openjdk.java.net Thu May 6 05:29:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 05:29:53 GMT Subject: Withdrawn: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From xliu at openjdk.java.net Thu May 6 06:01:01 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 06:01:01 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) In-Reply-To: References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: <3ItR_CJEO6mVIIBMdZunzn532rAmoFZiu0C_OBRiAAU=.93960808-8b58-4e1a-8f73-78c5d66ba41e@github.com> On Thu, 6 May 2021 05:26:40 GMT, Thomas Stuefe wrote: > Really? It decreases your planned message buffer size, no? Yes, I am happy to see it reduces the size of each payload. but sometimes smaller memory footprint doesn't change to runtime performance directly. From my measurement, LogDecoration doesn't impact that much. Check out this performance comparison. I found that copying 20 bytes is almost identical to copying 256 bytes. https://github.com/openjdk/jdk/pull/3855#issuecomment-832324143 ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From ksakata at openjdk.java.net Thu May 6 06:24:26 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:24:26 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: Change variable name to better one ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3448/files - new: https://git.openjdk.java.net/jdk/pull/3448/files/e37e8c50..d7b0627f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3448&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3448&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3448/head:pull/3448 PR: https://git.openjdk.java.net/jdk/pull/3448 From stuefe at openjdk.java.net Thu May 6 06:24:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 06:24:58 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size Message-ID: This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. What the patch does: In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. Additionally, patch adds gtests *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* Testing: - gtests, manually - jtreg runtime/logging, manually - SAP nightlies ran fine, but since then the tests changed, will run them again tonight ------------- Commit messages: - start - cherry-picked JDK-8266536 - harfbuzz-buildfix Changes: https://git.openjdk.java.net/jdk/pull/3874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266503 Stats: 153 lines in 8 files changed: 57 ins; 36 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/3874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3874/head:pull/3874 PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 06:45:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 06:45:49 GMT Subject: RFR: JDK-8266503: [ul] Make Decorations safely copy-able and reduce their size (first attempt, closed) In-Reply-To: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> References: <9mvjdES3a1_-p4gB8CzQhe4VFLhQgFNp4paNnhJv6eY=.eab569a1-b326-45d0-b7d6-2ed3340ca288@github.com> Message-ID: On Tue, 4 May 2021 15:05:43 GMT, Thomas Stuefe wrote: > In Universal Logging, class LogDecorations keeps resolved decorations as well as a lookup table of pointers to the start of each resolved decoration, by decorator. This is dangerous, since it makes object copy non-trivial (the pointers would need to be relocated). It is also wasteful since we spend 8 bytes per pointer per index. > > Better would be to use a numerical index array of offset values, which could be safely copied. > > And since the resolve buffer is 256 char, we can easily make this index an 8-bit value, which reduces the size of a LogDecorations object down to 280 bytes (from 368). Size matters especially in the context of JDK-8229517. > > The patch also adds a gtest, which tests that decorations are safely copy-able and that decorator resolution works as expected. > > Testing: > - manually jtreg runtime/logging > - manually gtests > - Will run more tests tonight > > Really? It decreases your planned message buffer size, no? > > Yes, I am happy to see it reduces the size of each payload. but sometimes smaller memory footprint doesn't change to runtime performance directly. From my measurement, LogDecoration doesn't impact that much. > > Check out this performance comparison. I found that copying 20 bytes is almost identical to copying 256 bytes. > [#3855 (comment)](https://github.com/openjdk/jdk/pull/3855#issuecomment-832324143) Oh sure. But I never claimed this to be performance relevant. Its all about memory. ------------- PR: https://git.openjdk.java.net/jdk/pull/3855 From ksakata at openjdk.java.net Thu May 6 06:55:59 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:55:59 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 06:24:26 GMT, Koichi Sakata wrote: >> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. >> >> >> $ java -Xlog::sample.log:: Sample >> $ jcmd 4976 VM.log list >> Log output configuration: >> #0: stdout all=warning uptime,level,tags >> #1: stderr all=off uptime,level,tags >> #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K >> >> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" >> 4976: >> Output options for existing outputs are ignored. >> >> $ jcmd 4976 VM.log output="#2" output_options="filecount=100" >> 4976: >> Command executed successfully >> >> >> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. >> >> >> $ jcmd 4976 VM.log list >> #0: stdout all=warning uptime,level,tags >> #1: stderr all=off uptime,level,tags >> #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) >> >> This pull request enable to show the warning message when specifying the output index. >> >> >> $ java -Xlog::sample.log:: Sample >> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" >> 5054: >> Output options for existing outputs are ignored. >> >> $ jcmd 5054 VM.log output="#2" output_options="filecount=100" >> 5054: >> Output options for existing outputs are ignored. >> >> >> ### gtest result >> >> >> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* >> Note: Google Test filter = LogConfigurationTest.* >> [==========] Running 15 tests from 1 test case. >> [----------] Global test environment set-up. >> [----------] 15 tests from LogConfigurationTest >> [ RUN ] LogConfigurationTest.describe_vm >> [ OK ] LogConfigurationTest.describe_vm (1 ms) >> [ RUN ] LogConfigurationTest.update_output_vm >> [ OK ] LogConfigurationTest.update_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.add_new_output_vm >> [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.disable_logging_vm >> [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) >> [ RUN ] LogConfigurationTest.disable_output_vm >> [ OK ] LogConfigurationTest.disable_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.reconfigure_decorators_vm >> [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) >> [ RUN ] LogConfigurationTest.invalid_configure_options_vm >> [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) >> [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm >> [0.462s][warning][logging] Ignoring excess -Xlog options: "" >> [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) >> [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm >> [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) >> [ RUN ] LogConfigurationTest.parse_log_arguments_vm >> [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) >> [ RUN ] LogConfigurationTest.configure_stdout_vm >> [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) >> [ RUN ] LogConfigurationTest.subscribe_vm >> [ OK ] LogConfigurationTest.subscribe_vm (2 ms) >> [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm >> [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) >> [ RUN ] LogConfigurationTest.output_name_normalization_vm >> [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) >> [ RUN ] LogConfigurationTest.suggest_similar_selection_vm >> [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) >> [----------] 15 tests from LogConfigurationTest (658 ms total) >> >> [----------] Global test environment tear-down >> [==========] 15 tests from 1 test case ran. (659 ms total) >> [ PASSED ] 15 tests. > > Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: > > Change variable name to better one Thank you for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From ksakata at openjdk.java.net Thu May 6 06:56:00 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:56:00 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 23:50:16 GMT, David Holmes wrote: >> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: >> >> Change variable name to better one > > src/hotspot/share/logging/logConfiguration.cpp line 430: > >> 428: ConfigurationLock cl; >> 429: size_t idx; >> 430: bool is_added = false; > > Nit: `was_added` (or even just `added`) Thank you, David. I changed `is_added` to `added`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From lzang at openjdk.java.net Thu May 6 08:45:45 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 6 May 2021 08:45:45 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request incrementally with one additional commit since the last revision: code refine and typo fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2261/files - new: https://git.openjdk.java.net/jdk/pull/2261/files/6d14790a..bf6d022e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=20-21 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From pli at openjdk.java.net Thu May 6 08:51:55 2021 From: pli at openjdk.java.net (Pengfei Li) Date: Thu, 6 May 2021 08:51:55 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels This test is in tier1. Shall we ProblemList it if we can't fix it in a short time? ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 08:59:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 08:59:53 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v2] In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 05:59:43 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels We cannot problemlist it for older kernels only, unfortunately. @kstefanj could you have a look at this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From simonis at openjdk.java.net Thu May 6 09:08:52 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 6 May 2021 09:08:52 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Wed, 5 May 2021 04:31:57 GMT, Thomas Stuefe wrote: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas Change looks good. I have just two minor questions (see inline). Thanks for adding the gtest! test/hotspot/gtest/runtime/test_os.cpp line 766: > 764: const size_t lp = strlen(pattern); > 765: const size_t ls = strlen(s); > 766: if (ls < lp) { Shouldn't this be `!=`? test/hotspot/gtest/runtime/test_os.cpp line 800: > 798: tty->print_cr("%s", result); > 799: EXPECT_EQ(result, buffer); > 800: EXPECT_TRUE(very_simple_string_matcher(pattern, result)); Do you intentionally repeat this same test for a second time? Does it provide any benefit? ------------- Changes requested by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 09:41:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 09:41:01 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:02:49 GMT, Volker Simonis wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> Thanks, Thomas > > test/hotspot/gtest/runtime/test_os.cpp line 766: > >> 764: const size_t lp = strlen(pattern); >> 765: const size_t ls = strlen(s); >> 766: if (ls < lp) { > > Shouldn't this be `!=`? I wanted to be able to give prefix pattern which do not cover the whole string. > test/hotspot/gtest/runtime/test_os.cpp line 800: > >> 798: tty->print_cr("%s", result); >> 799: EXPECT_EQ(result, buffer); >> 800: EXPECT_TRUE(very_simple_string_matcher(pattern, result)); > > Do you intentionally repeat this same test for a second time? Does it provide any benefit? Oops, no, this is an oversight. I'll remove the second test, thanks for catching this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From simonis at openjdk.java.net Thu May 6 09:43:58 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 6 May 2021 09:43:58 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:09:35 GMT, Thomas Stuefe wrote: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight Hi Thomas, your change looks good and I like it :) Am I right that you've changed the 256-char-for-all-decorators limit to a 255-char limit for a single decorator (which is obviously much better)? Find my other comments inline. Thank you and best regards, Volker src/hotspot/share/logging/logDecorations.cpp line 92: > 90: void LogDecorations::print_time_decoration(outputStream* st) const { > 91: char buf[29]; > 92: st->print_raw(os::iso8601_time(_millis, buf, sizeof(buf), false)); You have no error handling here. `os::iso8601_time()` can return `NULL` and `print_raw()` will call `strlen(NULL)` which will crash. Do something like: char *result = os::iso8601_time(_millis, buf, sizeof(buf), false); st->print_raw(result == NULL ? "-1" : result); Notice that the previous implementation was buggy as well. If `os::iso8601_time()` returned `NULL` it would have called `ASSERT_AND_RETURN(-1, pos)` which would have overwritten the last character in `pos` for non-product builds. It could also lead in a buffer-underflow if `pos` pointed to the very first character of an array. src/hotspot/share/logging/logDecorations.cpp line 97: > 95: void LogDecorations::print_utctime_decoration(outputStream* st) const { > 96: char buf[29]; > 97: st->print_raw(os::iso8601_time(_millis, buf, sizeof(buf), true)); Same as for `LogDecorations::print_time_decoration()`. src/hotspot/share/logging/logDecorations.cpp line 134: > 132: void LogDecorations::print_tags_decoration(outputStream* st) const { > 133: char tmp[255]; > 134: _tagset.label(tmp, sizeof(tmp)); // Todo: add a LogTagSet::label(outputStream*) to avoid this copy step Yes, that would be desirable and probably not too hard :) Otherwise you'll might have an uninitialized `tmp` array if the first tag doesn't fir into the array and `LogTagSet::label()` returns `-1`. I understand that that's more a theoretical problem because at least one tag should always fir within 255 characters :) src/hotspot/share/logging/logDecorations.hpp line 42: > 40: const jlong _nanos; // for "timenanos" > 41: const double _elapsed_seconds; // for "uptime", "uptimemillis", "uptimenanos" > 42: const int _pid; // for "pid" You can use the same trick for `_pid` (i.e. make it static and resolve it a single time) like for `_host_name`. That will save you another 4 bytes for the size of `LogDecorations`. test/hotspot/gtest/logging/test_logDecorations.cpp line 35: > 33: > 34: TEST_VM(LogDecorations, level) { > 35: char buf[1024]; Minor nit: in `LogFileStreamOutput::write_decorations()` you are using a temporary buffer of 255 charaters so you should use the same buffer size for testing. Ideally you can make that a constant or macro which can be reused here in the tests. ------------- Changes requested by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3874 From shade at openjdk.java.net Thu May 6 09:49:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 09:49:37 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: > See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into JDK-8263236-trace-page-sizes - Merge branch 'master' into JDK-8263236-trace-page-sizes - Merge branch 'master' into JDK-8263236-trace-page-sizes - Make jcheck happy: remove the TAB - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3415/files - new: https://git.openjdk.java.net/jdk/pull/3415/files/6db67d61..c7a6136c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=01-02 Stats: 606892 lines in 6200 files changed: 68511 ins; 525738 del; 12643 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 09:55:22 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 09:55:22 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v2] In-Reply-To: References: Message-ID: <_7OfCgYLQ3ZJVk9VcRWUqJd5xeXYYuvHdiHwhA2x4hI=.170010f1-b2be-41ea-a3c0-f7aa5f3e1ca1@github.com> > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Remove duplicate coding in gtest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3869/files - new: https://git.openjdk.java.net/jdk/pull/3869/files/bfa41f13..942b4324 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3869/head:pull/3869 PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 09:55:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 09:55:23 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:06:20 GMT, Volker Simonis wrote: > Change looks good. I have just two minor questions (see inline). > > Thanks for adding the gtest! Thanks Volker! ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From sjohanss at openjdk.java.net Thu May 6 09:58:02 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 09:58:02 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:49:37 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Sorry, totally missed this PR. I saw the bug-report a while back and hoped my recent refactoring would help the situation, but I guess it only made things worse? Will take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 09:58:13 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 09:58:13 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:49:37 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels I am looking at it too, since I have a machine where this failure reproduces reliably. Looks to me, G1 tests fail, while Serial/Parallel pass with this patch. Maybe there was a G1-specific fix somewhere that breaks this test? ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 10:06:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 10:06:16 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:49:37 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels I notice that the failures are like this with debug turned on: >From logfile: [0.004s][info][pagesize] CodeHeap 'non-nmethods': min=4M max=8M base=0x00007fffd9200000 page_size=2M size=8M >From smaps: [7fffd9200000, 7fffd9600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false >From logfile: [0.011s][info][pagesize] Block Offset Table: req_size=2580K base=0x00007fffd7400000 page_size=2M alignment=2M size=4M >From smaps: [7fffd7400000, 7fffd7600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false So these probably are not committed yet, because `-XX:+AlwaysPreTouch` (set by test) do not affect them. (sighs) ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From sjohanss at openjdk.java.net Thu May 6 10:12:57 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 10:12:57 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:02:45 GMT, Aleksey Shipilev wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Make jcheck happy: remove the TAB >> - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels > > I notice that the failures are like this with debug turned on: > > > From logfile: [0.004s][info][pagesize] CodeHeap 'non-nmethods': min=4M max=8M base=0x00007fffd9200000 page_size=2M size=8M > From smaps: [7fffd9200000, 7fffd9600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false > > > > From logfile: [0.011s][info][pagesize] Block Offset Table: req_size=2580K base=0x00007fffd7400000 page_size=2M alignment=2M size=4M > From smaps: [7fffd7400000, 7fffd7600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false > > > So these probably are not committed yet, because `-XX:+AlwaysPreTouch` (set by test) do not affect them. (sighs) @shipilev, do you know which change did break the test again, I did a few different cleanup that are related. @shipilev, that sounds like a valid theory. But not sure why that should have changed recently. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 10:13:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 10:13:03 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:02:45 GMT, Aleksey Shipilev wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Merge branch 'master' into JDK-8263236-trace-page-sizes >> - Make jcheck happy: remove the TAB >> - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels > > I notice that the failures are like this with debug turned on: > > > From logfile: [0.004s][info][pagesize] CodeHeap 'non-nmethods': min=4M max=8M base=0x00007fffd9200000 page_size=2M size=8M > From smaps: [7fffd9200000, 7fffd9600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false > > > > From logfile: [0.011s][info][pagesize] Block Offset Table: req_size=2580K base=0x00007fffd7400000 page_size=2M alignment=2M size=4M > From smaps: [7fffd7400000, 7fffd7600000) anonHugePages = 0 pageSize=4KB isTHP=false isHUGETLB=false > > > So these probably are not committed yet, because `-XX:+AlwaysPreTouch` (set by test) do not affect them. (sighs) > @shipilev, do you know which change did break the test again, I did a few different cleanup that are related. Don't know yet. But I think this kind of failure highlights that tracking `AnonHugePages` is not fool-proof either: we implicitly rely on allocations/commit happen in that area to have AHP != 0. Which is doable for Java heap with `-XX:+AlwaysPreTouch`, but not for VM areas. There are various -XX:+Zap* flags, but they do not cover every VM area. > @shipilev, that sounds like a valid theory. But not sure why that should have changed recently. I am now not even sure that the test passed reliably during my first attempt. All 6 subtests intermittently pass/fails with this patch. Let me mull over this a bit. Maybe the saner way out would be checking the kernel version and bailing on older kernels. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From sjohanss at openjdk.java.net Thu May 6 10:18:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 10:18:51 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: <68u6AHhVpXyK6VrZIRsoWFLbrQHVJqhQ1gVxxeuuSBI=.a78b6384-562e-44bb-b58e-1b433e9c7e63@github.com> On Thu, 6 May 2021 10:10:23 GMT, Aleksey Shipilev wrote: > Let me mull over this a bit. Maybe the saner way out would be checking the kernel version and bailing on older kernels. That would be one approach, when I first started to think about supporting THP for the test I looked at a few different ways including `AnonHugePages` but the one that was most reliable was to check the flag. I would be totally ok with excluding the test for older kernels, not sure if we have a good way to figure this out or if we have to do some parsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From ysuenaga at openjdk.java.net Thu May 6 10:31:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 6 May 2021 10:31:52 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:09:35 GMT, Thomas Stuefe wrote: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 378: > 376: { > 377: machine_index_t (const Iter& it) : it (it) {} > 378: machine_index_t (const machine_index_t& o) : hb_iter_with_fallback_t, typename Iter::item_t>(o), it (o.it) {} This change does not seem to be for this PR... ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From shade at openjdk.java.net Thu May 6 10:46:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 10:46:15 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: > See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - No tabs - Just ignore on older kernels ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3415/files - new: https://git.openjdk.java.net/jdk/pull/3415/files/c7a6136c..5bf7827c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=02-03 Stats: 81 lines in 1 file changed: 21 ins; 40 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 10:46:28 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 10:46:28 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v3] In-Reply-To: References: Message-ID: <-5xuDa6DFKLtMUCpvsPGW_X3qbvNsKE4XT19XbKqJsg=.09c3dd11-bf86-4d9b-8b4d-5a8323f9b3c4@github.com> On Thu, 6 May 2021 09:49:37 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Merge branch 'master' into JDK-8263236-trace-page-sizes > - Make jcheck happy: remove the TAB > - 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Ran out of ideas. New version checks for kernel version and bails on kernels lower than 5.x. I shall try and see if I can find the more precise kernel version where this was fixed. Meanwhile, would the coarse check like this work, if I could not find a more precise version? ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 11:07:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 11:07:54 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:40:42 GMT, Volker Simonis wrote: > Hi Thomas, > > your change looks good and I like it :) :-) > > Am I right that you've changed the 256-char-for-all-decorators limit to a 255-char limit for a single decorator (which is obviously much better)? yes - and even that can be improved by using a fileStream directly, not raw jio_fprintf. > > Find my other comments inline. > > Thank you and best regards, > Volker Thanks! > You have no error handling here. `os::iso8601_time()` can return `NULL` and `print_raw()` will call `strlen(NULL)` which will crash. Do something like: > > ``` > char *result = os::iso8601_time(_millis, buf, sizeof(buf), false); > st->print_raw(result == NULL ? "-1" : result); > ``` Good catch, I missed that. Note that I think os::iso8601_time() could be made nicer - in my opinion, any API returning the output buffer for convenience should not return NULL, because that defeats the purpose. > > Notice that the previous implementation was buggy as well. If `os::iso8601_time()` returned `NULL` it would have called `ASSERT_AND_RETURN(-1, pos)` which would have overwritten the last character in `pos` for non-product builds. It could also lead in a buffer-underflow if `pos` pointed to the very first character of an array. You are right. Nice to see this fixed. > src/hotspot/share/logging/logDecorations.cpp line 97: > >> 95: void LogDecorations::print_utctime_decoration(outputStream* st) const { >> 96: char buf[29]; >> 97: st->print_raw(os::iso8601_time(_millis, buf, sizeof(buf), true)); > > Same as for `LogDecorations::print_time_decoration()`. +1 > src/hotspot/share/logging/logDecorations.cpp line 134: > >> 132: void LogDecorations::print_tags_decoration(outputStream* st) const { >> 133: char tmp[255]; >> 134: _tagset.label(tmp, sizeof(tmp)); // Todo: add a LogTagSet::label(outputStream*) to avoid this copy step > > Yes, that would be desirable and probably not too hard :) > > Otherwise you'll might have an uninitialized `tmp` array if the first tag doesn't fir into the array and `LogTagSet::label()` returns `-1`. I understand that that's more a theoretical problem because at least one tag should always fir within 255 characters :) My fist version had this but Xin mentioned the patch was too large :) I'll reinstate my first solution. > src/hotspot/share/logging/logDecorations.hpp line 42: > >> 40: const jlong _nanos; // for "timenanos" >> 41: const double _elapsed_seconds; // for "uptime", "uptimemillis", "uptimenanos" >> 42: const int _pid; // for "pid" > > You can use the same trick for `_pid` (i.e. make it static and resolve it a single time) like for `_host_name`. That will save you another 4 bytes for the size of `LogDecorations`. Good point. Might even be more because of padding. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 11:07:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 11:07:55 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:09:35 GMT, Thomas Stuefe wrote: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight src/hotspot/share/runtime/os.cpp line 102: > 100: va_end(args); > 101: return result; > 102: } Reviewer Note: not part of this patch: see https://github.com/openjdk/jdk/pull/3869 src/hotspot/share/runtime/os.hpp line 224: > 222: // It is MT safe, but not async-safe, as reading time zone > 223: // information may require a lock on some platforms. > 224: static char* local_time_string(char *buf, size_t buflen); Reviewer Note: not part of this patch: see #3869 src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 375: > 373: struct machine_index_t : > 374: hb_iter_with_fallback_t, > 375: typename Iter::item_t> Reviewer Note: not part of this patch: This is a compile fix for the broken harfbuzz build, see https://github.com/openjdk/jdk/pull/3873. Will remove this before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 11:07:56 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 11:07:56 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: <1kpXXKV0IlNKqoM0a-9WfYqYL0xtvO5suXJVOoXuHjE=.130554d0-0e24-4a12-bc0e-831f29b289c0@github.com> On Thu, 6 May 2021 10:28:47 GMT, Yasumasa Suenaga wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use-machine.hh line 378: > >> 376: { >> 377: machine_index_t (const Iter& it) : it (it) {} >> 378: machine_index_t (const machine_index_t& o) : hb_iter_with_fallback_t, typename Iter::item_t>(o), it (o.it) {} > > This change does not seem to be for this PR... Yes, this is a harfbuzz related build fix, see initial note. I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From sjohanss at openjdk.java.net Thu May 6 11:13:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 11:13:55 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:46:15 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - No tabs > - Just ignore on older kernels Looks good to me. The `isLinux()` check should not be needed since we require this to only run on Linux. But it won't hurt and makes it more clear so I'm good with it. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 11:17:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 11:17:53 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: <9i57V_5soE8kVIEZLS3zCl4Qy5CO3e5Vt9sIXnyfi6Y=.581a66da-52bc-4476-9bd0-d020dd66e3f3@github.com> On Thu, 6 May 2021 11:02:02 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logDecorations.hpp line 42: >> >>> 40: const jlong _nanos; // for "timenanos" >>> 41: const double _elapsed_seconds; // for "uptime", "uptimemillis", "uptimenanos" >>> 42: const int _pid; // for "pid" >> >> You can use the same trick for `_pid` (i.e. make it static and resolve it a single time) like for `_host_name`. That will save you another 4 bytes for the size of `LogDecorations`. > > Good point. Might even be more because of padding. ... hah, wouldn't you know, its down to 48 bytes :-) BTW I think if we look closer we can probably squeeze this even more. E.g. _millis and _nanos are kind of the same thing; for _elapsedSeconds a float may be sufficient instead of a double; and tagset could be made a bitmaks (it really really should be one) and passed as 32bit value object instead of as a reference. But I wanted to keep the patch small and concise for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 12:00:21 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 12:00:21 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight 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: - Merge - Remove harfbuzz build fix - Volker feedback - start - cherry-picked JDK-8266536 - harfbuzz-buildfix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3874/files - new: https://git.openjdk.java.net/jdk/pull/3874/files/9df5a1f8..3a357557 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=00-01 Stats: 1993 lines in 75 files changed: 1503 ins; 376 del; 114 mod Patch: https://git.openjdk.java.net/jdk/pull/3874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3874/head:pull/3874 PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 12:05:59 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 12:05:59 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:40:42 GMT, Volker Simonis 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 six additional commits since the last revision: >> >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > Hi Thomas, > > your change looks good and I like it :) > > Am I right that you've changed the 256-char-for-all-decorators limit to a 255-char limit for a single decorator (which is obviously much better)? > > Find my other comments inline. > > Thank you and best regards, > Volker Hi @simonis , @YaSuenag , thanks for your Reviews! New version - mostly driven by Volkers feedback: - I now cache the pid, which further reduces the size of this object to 48. As mentioned in https://github.com/openjdk/jdk/pull/3874#discussion_r627326425, one could further reduce it but I think this is already fine. - I added `LogDecorations::max_decoration_size` and used it for temp buffers. Note that this limit would be easy to remove by using `fileStream` in `LogFileStreamOutput::write_decorations()` - however, `fileStream` misses some functionality and I wanted to limit the patch size. - I fixed the error handling for `os::iso8601_time()` - I added a overload to `LogTagSet` which takes an `outputStream` - this is more elegant and prevents the copy. I also added a gtest for this function - I removed the harfbuzz build fix Thanks for reviewing! ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 12:08:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 12:08:53 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:46:15 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - No tabs > - Just ignore on older kernels Looks good to me too. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3415 From ksakata at openjdk.java.net Thu May 6 12:11:02 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 12:11:02 GMT Subject: Integrated: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. This pull request has now been integrated. Changeset: 51f5adfc Author: Koichi Sakata Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/51f5adfca3854b1556bb73e08e0b3e733ab6161b Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod 8265047: Inconsistent warning message in jcmd VM.log Reviewed-by: dholmes, stuefe, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From sjohanss at openjdk.java.net Thu May 6 12:15:54 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 12:15:54 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:46:15 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - No tabs > - Just ignore on older kernels Just realized one thing... you might be able to solve it with just adding to the `@requires` line as well, something like: `@requires os.family == "linux" & os.simpleVersion >= 5` But I'm not sure if `>=` is allowed for `simpleVersion` and I'm not at all sure how `simpleVersion`is made available. Maybe it is a Mac thing, the only tests using it only matters for Mac. Maybe `os.versionMajor` is available to use. If you like this approach maybe you can try and see if it works. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 12:23:14 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 12:23:14 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > 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 seven additional commits since the last revision: - Merge - remove harfbuzz fix - Remove duplicate coding in gtest - gtest for os.iso8601_time should use utc - Build fix for Harfbuzz - Merge - start ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3869/files - new: https://git.openjdk.java.net/jdk/pull/3869/files/942b4324..40f23a23 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=01-02 Stats: 2297 lines in 100 files changed: 1553 ins; 600 del; 144 mod Patch: https://git.openjdk.java.net/jdk/pull/3869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3869/head:pull/3869 PR: https://git.openjdk.java.net/jdk/pull/3869 From hseigel at openjdk.java.net Thu May 6 12:28:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 6 May 2021 12:28:53 GMT Subject: RFR: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:55:16 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. >> >> The fix was tested with Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Update test Thanks David, Coleen, Misha and Lois for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3882 From hseigel at openjdk.java.net Thu May 6 12:28:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 6 May 2021 12:28:55 GMT Subject: Integrated: 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes In-Reply-To: References: Message-ID: On Wed, 5 May 2021 12:49:20 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8266496. The fix changes WBIsKlassAliveClosure.do_klass() so that when it compares the specified name with the name of a hidden class, it truncates the hidden class's name at the first '+' character before doing the comparison. This should work except in the rare case when the pre-mangled hidden class name contains a '+' character. > > The fix 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: eb3b96d8 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/eb3b96d86b7fd21d444bb09c032b424e61bc5d6f Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod 8266496: WBIsKlassAliveClosure.do_klass() fails for hidden classes Reviewed-by: dholmes, coleenp, mseledtsov, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/3882 From stuefe at openjdk.java.net Thu May 6 12:36:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 12:36:53 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: <5jEpLSvxNmBXWcL04Cz2hBORoFj8lahncTvSLKP3NlU=.4ca25328-4d00-4aad-9aae-2e0b5f2d76d6@github.com> On Thu, 6 May 2021 10:46:15 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - No tabs > - Just ignore on older kernels Should we just handle AlwaysPretouch directly in os::reserve_memory() instead of having each caller do this? Or would this interfere with concurrent pretouching? ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From sjohanss at openjdk.java.net Thu May 6 12:44:59 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 12:44:59 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:46:15 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. Instead, we can use a secondary evidence and read `AnonHugePages`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - No tabs > - Just ignore on older kernels In theory this would be good, but as you say it would make parallel/concurrent pre-touch harder. Or at least we would have to extend a lot of APIs to pass down the needed work gang. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From hseigel at openjdk.java.net Thu May 6 13:06:05 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 6 May 2021 13:06:05 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v7] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 02:12:17 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix comments Changes look good. Thanks for fixing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3392 From ysuenaga at openjdk.java.net Thu May 6 13:30:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 6 May 2021 13:30:56 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: <8J6edXLZJGf8MPlvui4A0rTXIPT6g5MaOCk9QeuHDFU=.9e079f19-0d8f-4d83-816d-83aea82a9c70@github.com> On Thu, 6 May 2021 12:00:21 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > 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: > > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix Looks good! src/hotspot/share/logging/logDecorations.cpp line 90: > 88: > 89: void LogDecorations::print_time_decoration(outputStream* st) const { > 90: char buf[29]; nit: "29" might be better to define some constant e.g. "ISO8601_LEN". But it should might be better to happen in #3869. ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3874 From hseigel at openjdk.java.net Thu May 6 13:40:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 6 May 2021 13:40:52 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: Message-ID: <-Y57GngMowbZh4Qk8xccqqWJx7aizXf2rRrImc3lCyg=.3eac7dc6-c786-4866-85d3-7d400b9e63e3@github.com> On Wed, 5 May 2021 20:57:18 GMT, Joe Darcy wrote: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. src/hotspot/share/classfile/classFileParser.cpp line 4802: > 4800: // those flags are illegal irrespective of ACC_ABSTRACT being set or not. > 4801: (is_abstract && > 4802: (is_private || is_static || (major_gte_17 ? false : is_strict)))) { Lines 4802 and 4830 would be simpler if changed to: (is_private || is_static || (!major_gte_17 && is_strict)))) { test/hotspot/jtreg/runtime/strictfp/StrictfpModifierChecksTest.java line 56: > 54: throw new RuntimeException("Should not reach; expected ClassFormatError not thrown"); > 55: } catch (ClassFormatError cfe) { > 56: ; // Expected Could you add something like the following to ensure that the right ClassFormatError exception is being thrown: String eMsg = cfe.getMessage(); if (!eMsg.contains("has illegal modifier")) { throw new RuntimeException("Unexpected exception message: " + eMsg); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From simonis at openjdk.java.net Thu May 6 13:47:56 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 6 May 2021 13:47:56 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 12:23:14 GMT, Thomas Stuefe wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> 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 seven additional commits since the last revision: > > - Merge > - remove harfbuzz fix > - Remove duplicate coding in gtest > - gtest for os.iso8601_time should use utc > - Build fix for Harfbuzz > - Merge > - start Looks good, thanks. ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3869 From dholmes at openjdk.java.net Thu May 6 13:59:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 6 May 2021 13:59:55 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v7] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 02:12:17 GMT, Wang Huang wrote: >> As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix comments Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From shade at openjdk.java.net Thu May 6 14:05:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 14:05:18 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v5] In-Reply-To: References: Message-ID: > See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. > Rough kernel bisection shows that the hints are reliable since kernel 4.15. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) > - [x] Test with kernel 4.15 (still passes) > - [x] Test with kernel 4.14.17 (used to fail, now passes) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: More precise version, after rough kernel bisection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3415/files - new: https://git.openjdk.java.net/jdk/pull/3415/files/5bf7827c..1df37de7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 14:27:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 14:27:53 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v5] In-Reply-To: References: Message-ID: <8XULFY9nlkSU8eBqaonWiH-eGvzKqv70XkfPX7bbn9Y=.d574095e-aa5d-4087-a39a-783910c0a155@github.com> On Thu, 6 May 2021 14:05:18 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. >> Rough kernel bisection shows that the hints are reliable since kernel 4.15. >> There are plenty of changes between 4.14.17 and 4.15, none seem obvious as the culprits. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) >> - [x] Test with kernel 4.15 (still passes) >> - [x] Test with kernel 4.14.17 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More precise version, after rough kernel bisection Okay, I did a rough bisect over pre-built Debian kernels, and that points to `4.15` as the first kernel that works. I updated the PR changeset and PR description accordingly. I am still struggling to find a particular commit that solved it, so I can explain to myself why this works... Anyhow, the version check would not get more precise that this, since we only have major and minor OS versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From ddong at openjdk.java.net Thu May 6 14:34:14 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 6 May 2021 14:34:14 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function Message-ID: JDK-8249719 has fixed the bad hash function problem, however, when there are a large number of classes with the same name, there are still performance problems. Add the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. ------------- Commit messages: - 8266642: improve ResolvedMethodTable hash function Changes: https://git.openjdk.java.net/jdk/pull/3901/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266642 Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From sjohanss at openjdk.java.net Thu May 6 15:32:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 15:32:55 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 14:05:18 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. >> Rough kernel bisection shows that the hints are reliable since kernel 4.15. >> There are plenty of changes between 4.14.17 and 4.15, none seem obvious as the culprits. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) >> - [x] Test with kernel 4.15 (still passes) >> - [x] Test with kernel 4.14.17 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More precise version, after rough kernel bisection ?? ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 16:12:50 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 16:12:50 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 13:44:34 GMT, Volker Simonis wrote: > Looks good, thanks. Thank you Volker! ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 16:15:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 16:15:00 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: <8J6edXLZJGf8MPlvui4A0rTXIPT6g5MaOCk9QeuHDFU=.9e079f19-0d8f-4d83-816d-83aea82a9c70@github.com> References: <8J6edXLZJGf8MPlvui4A0rTXIPT6g5MaOCk9QeuHDFU=.9e079f19-0d8f-4d83-816d-83aea82a9c70@github.com> Message-ID: On Thu, 6 May 2021 13:27:46 GMT, Yasumasa Suenaga 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 six additional commits since the last revision: >> >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > src/hotspot/share/logging/logDecorations.cpp line 90: > >> 88: >> 89: void LogDecorations::print_time_decoration(outputStream* st) const { >> 90: char buf[29]; > > nit: "29" might be better to define some constant e.g. "ISO8601_LEN". But it should might be better to happen in #3869. > Looks good! Thanks! I'll add the constant in the other PR ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 16:15:50 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 16:15:50 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 12:42:06 GMT, Stefan Johansson wrote: > In theory this would be good, but as you say it would make parallel/concurrent pre-touch harder. Or at least we would have to extend a lot of APIs to pass down the needed work gang. Or make this an optional part of reservation, to be controlled by yet anther argument (sigh - maybe not :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From minqi at openjdk.java.net Thu May 6 16:29:32 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 16:29:32 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v3] In-Reply-To: References: Message-ID: <8fMjK5oCjC9P53PPQ56P-oHIuj8PImVj8m-RWpw-WrY=.f932094b-8936-40e7-9d6c-692564a2f293@github.com> > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed temp file operation, archive and temp file name consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/b420da7b..83478dd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=01-02 Stats: 289 lines in 5 files changed: 120 ins; 138 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From darcy at openjdk.java.net Thu May 6 17:40:27 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 6 May 2021 17:40:27 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v2] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/a58dac20..bef3958f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=00-01 Stats: 16 lines in 2 files changed: 6 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From darcy at openjdk.java.net Thu May 6 17:40:33 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 6 May 2021 17:40:33 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v2] In-Reply-To: <-Y57GngMowbZh4Qk8xccqqWJx7aizXf2rRrImc3lCyg=.3eac7dc6-c786-4866-85d3-7d400b9e63e3@github.com> References: <-Y57GngMowbZh4Qk8xccqqWJx7aizXf2rRrImc3lCyg=.3eac7dc6-c786-4866-85d3-7d400b9e63e3@github.com> Message-ID: <0vJzcG7ix7ik4GLeCxKhkMV999VHqZNuvFASwm5yqgs=.03da80db-6115-49f2-8dee-231fce40edc2@github.com> On Thu, 6 May 2021 13:34:32 GMT, Harold Seigel wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/hotspot/share/classfile/classFileParser.cpp line 4802: > >> 4800: // those flags are illegal irrespective of ACC_ABSTRACT being set or not. >> 4801: (is_abstract && >> 4802: (is_private || is_static || (major_gte_17 ? false : is_strict)))) { > > Lines 4802 and 4830 would be simpler if changed to: > (is_private || is_static || (!major_gte_17 && is_strict)))) { Suggested changes here and in the test made; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From xliu at openjdk.java.net Thu May 6 18:01:10 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 18:01:10 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: <2aPyX4B-ZqXKNMWyxrM3Kh5pmR2aUMcYPs-ZeH8VeCg=.4049b882-e1ac-4354-9ac9-5a7b8b70772c@github.com> On Thu, 6 May 2021 12:00:21 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > 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: > > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix src/hotspot/share/logging/logDecorations.cpp line 39: > 37: if (os::get_host_name(buffer, sizeof(buffer))) { > 38: // Use raw malloc here > 39: return ::strdup(buffer); I don't think `strdup` is necessary. If you decide to use static variable, you can use `static char buffer[1024]` in the function. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From shade at openjdk.java.net Thu May 6 18:15:29 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 18:15:29 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: > See the bug report for details. On some kernels, the madvise hint is not reflected in `/proc/smaps`. > Rough kernel bisection shows that the hints are reliable since kernel 4.15. > There are plenty of changes between 4.14.17 and 4.15, none seem obvious as the culprits. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) > - [x] Test with kernel 4.15 (still passes) > - [x] Test with kernel 4.14.17 (used to fail, now passes) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Even simpler patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3415/files - new: https://git.openjdk.java.net/jdk/pull/3415/files/1df37de7..66f84327 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3415&range=04-05 Stats: 25 lines in 1 file changed: 0 ins; 23 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3415/head:pull/3415 PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 18:15:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 18:15:31 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v5] In-Reply-To: <8XULFY9nlkSU8eBqaonWiH-eGvzKqv70XkfPX7bbn9Y=.d574095e-aa5d-4087-a39a-783910c0a155@github.com> References: <8XULFY9nlkSU8eBqaonWiH-eGvzKqv70XkfPX7bbn9Y=.d574095e-aa5d-4087-a39a-783910c0a155@github.com> Message-ID: On Thu, 6 May 2021 14:24:53 GMT, Aleksey Shipilev wrote: > Okay, I did a rough bisect over pre-built Debian kernels, and that points to `4.15` as the first kernel that works. I updated the PR changeset and PR description accordingly. I am still struggling to find a particular commit that solved it, so I can explain to myself why this works... All right. Here is a kicker. Vanilla `4.14.17` kernel is passing the tests, while Debian's `4.14.17` fails it! Looking at Debian kernel patches, I see a few suspicious ones. Applying [these patches](https://salsa.debian.org/kernel-team/linux/-/commit/3f937de4507cf678ebfa53654bee5ffe20d76ad6) to vanilla `4.14.17` also makes the test fail. This hunk from that Debian's kernel patch is apparently the problem: diff --git a/include/linux/mman.h b/include/linux/mman.h index 7c87b6652244..f22c15d5e24c 100644 --- a/include/linux/mman.h +++ b/include/linux/mman.h @@ -87,7 +87,8 @@ calc_vm_flag_bits(unsigned long flags) { return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) | _calc_vm_trans(flags, MAP_DENYWRITE, VM_DENYWRITE ) | - _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ); + _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ) | + _calc_vm_trans(flags, MAP_FIXED, VM_FIXED ); } It copies the mmap tags to the VMA flag. Now, that thing is getting printed in [show_smap_vma_flags](https://github.com/torvalds/linux/blob/master/fs/proc/task_mmu.c#L603-L681). Notice how that method prepares itself for missing flag cases by [printing `??`](https://github.com/torvalds/linux/blob/master/fs/proc/task_mmu.c#L609-L612). Indeed, Debian patch misses that addition, so we see `??` for some entries in `/proc/smaps`. How's that a problem for this test? Stare at this regexp: String smapsPatternString = "(\\w+)-(\\w+).*?" + "KernelPageSize:\\s*(\\d*) kB.*?" + "VmFlags: ([\\w ]*)"; `?` is _not_ `\w`, so the entire thing mismatches the moment the VMA flags have `??` in them. And this only happens on some Debian kernels, because you have to have that new unhandled flag. This also explains why `4.15` works, the [later commit](https://salsa.debian.org/kernel-team/linux/-/commit/7dd9b58675f9c285944cd6b12199481765c932a0#b23bf90ba1c0322d4a1bb8ace6fac27f98426b10_21_21) redefined that new flag to existing, handled value for `VM_ARCH`. So this is deserves a simple fix in the regexp itself: - "VmFlags: ([\\w ]*)"; + "VmFlags: ([\\w\? ]*)"; Testing that now... ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From sjohanss at openjdk.java.net Thu May 6 18:31:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 18:31:51 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:15:29 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, we have trouble parsing madvise tags from `/proc/smaps`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) >> - [x] Test with kernel 4.15 (still passes) >> - [x] Test with kernel 4.14.17 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Even simpler patch Great dig @shipilev ?? So the `hg` vmFlag is present for all kernels we care about? ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 18:32:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 18:32:57 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: <2aPyX4B-ZqXKNMWyxrM3Kh5pmR2aUMcYPs-ZeH8VeCg=.4049b882-e1ac-4354-9ac9-5a7b8b70772c@github.com> References: <2aPyX4B-ZqXKNMWyxrM3Kh5pmR2aUMcYPs-ZeH8VeCg=.4049b882-e1ac-4354-9ac9-5a7b8b70772c@github.com> Message-ID: <7abNNAEkHfH-1yVhrFo6hYIr4VwRrbosyky2LReQ2p0=.22979868-0bfa-4372-a220-3326f4e0d24e@github.com> On Wed, 5 May 2021 18:27:41 GMT, Xin Liu 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 six additional commits since the last revision: >> >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > src/hotspot/share/logging/logDecorations.cpp line 39: > >> 37: if (os::get_host_name(buffer, sizeof(buffer))) { >> 38: // Use raw malloc here >> 39: return ::strdup(buffer); > > I don't think `strdup` is necessary. If you decide to use static variable, you can use `static char buffer[1024]` in the function. Hi Xin, I think you review an old version, I reverted that coding. But the point about using a pointer and resolving hostname lazily on first access is to prevent paying anything if logging is off or logging is on but the hostname decorator is not used. For a static char array you always have to pay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From shade at openjdk.java.net Thu May 6 18:34:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 18:34:51 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:29:07 GMT, Stefan Johansson wrote: > So the `hg` vmFlag is present for all kernels we care about? Apparently. It is the test regexp that mismatches when kernel replies `??` for any other VMA flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From sjohanss at openjdk.java.net Thu May 6 18:40:54 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 6 May 2021 18:40:54 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:31:42 GMT, Aleksey Shipilev wrote: > > So the `hg` vmFlag is present for all kernels we care about? > > Apparently. It is the test regexp that mismatches when kernel replies `??` for any other VMA flag. Got that. Just wanted to make sure noone else had this problem because they were on an even older kernel where `ht` actually wasn't added. But even if that is the case this fix is good =) ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From shade at openjdk.java.net Thu May 6 18:45:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 18:45:55 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:38:26 GMT, Stefan Johansson wrote: > > > So the `hg` vmFlag is present for all kernels we care about? > > > > > > Apparently. It is the test regexp that mismatches when kernel replies `??` for any other VMA flag. > > Got that. Just wanted to make sure noone else had this problem because they were on an even older kernel where `ht` actually wasn't added. The way I see the kernel sources, `ht` is available since the day `VmFlags` field [was introduced](https://github.com/torvalds/linux/commit/834f82e2aa9a8ede94b17b656329f850c1471514) in the smaps. Unless there is a bug that corrupts the VMA flag somewhere, we should be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From stuefe at openjdk.java.net Thu May 6 18:45:56 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 18:45:56 GMT Subject: RFR: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels [v6] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:15:29 GMT, Aleksey Shipilev wrote: >> See the bug report for details. On some kernels, we have trouble parsing madvise tags from `/proc/smaps`. >> >> Additional testing: >> - [x] Test with kernel 5.4.0 (still passes) >> - [x] Test with kernel 4.9.0 (used to fail, now passes) >> - [x] Test with kernel 4.15 (still passes) >> - [x] Test with kernel 4.14.17 (used to fail, now passes) > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Even simpler patch Hah. Beautiful. And somewhat ironic, what are the odds that the offending patch was actually a workaround for a hotspot issue. +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From xliu at openjdk.java.net Thu May 6 18:46:56 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 18:46:56 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: <7abNNAEkHfH-1yVhrFo6hYIr4VwRrbosyky2LReQ2p0=.22979868-0bfa-4372-a220-3326f4e0d24e@github.com> References: <2aPyX4B-ZqXKNMWyxrM3Kh5pmR2aUMcYPs-ZeH8VeCg=.4049b882-e1ac-4354-9ac9-5a7b8b70772c@github.com> <7abNNAEkHfH-1yVhrFo6hYIr4VwRrbosyky2LReQ2p0=.22979868-0bfa-4372-a220-3326f4e0d24e@github.com> Message-ID: On Thu, 6 May 2021 18:30:16 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logDecorations.cpp line 39: >> >>> 37: if (os::get_host_name(buffer, sizeof(buffer))) { >>> 38: // Use raw malloc here >>> 39: return ::strdup(buffer); >> >> I don't think `strdup` is necessary. If you decide to use static variable, you can use `static char buffer[1024]` in the function. > > Hi Xin, I think you review an old version, I reverted that coding. > > But the point about using a pointer and resolving hostname lazily on first access is to prevent paying anything if logging is off or logging is on but the hostname decorator is not used. For a static char array you always have to pay. Sorry. forget it. I commented yesterday and just sent out. I see you revert host_name(). The reason to use lazy initialization is fair enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From vromero at openjdk.java.net Thu May 6 19:06:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 May 2021 19:06:41 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v7] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05-06 Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From xliu at openjdk.java.net Thu May 6 19:09:59 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 19:09:59 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 12:00:21 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > 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: > > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix src/hotspot/share/logging/logTagSet.hpp line 116: > 114: > 115: void label(outputStream* st, const char* separator = ",") const; > 116: int label(char *buf, size_t len, const char* separator = ",") const; This old label() is only used in LogTagset. You can make it private. Further, no one consumes its return value now. you can change its rettypea void. it will avoid different return types for overloaded member functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From xliu at openjdk.java.net Thu May 6 19:20:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 19:20:57 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 12:23:14 GMT, Thomas Stuefe wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> 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 seven additional commits since the last revision: > > - Merge > - remove harfbuzz fix > - Remove duplicate coding in gtest > - gtest for os.iso8601_time should use utc > - Build fix for Harfbuzz > - Merge > - start src/hotspot/share/runtime/os.hpp line 231: > 229: // E.g., YYYY-MM-DDThh:mm:ss.mmm+zzzz. > 230: // Returns buffer, or NULL if it failed. > 231: static char* iso8601_time(jlong milliseconds_since_19700101, char buffer[29], You are supposed to get a compiler warning on this char buffer[29]. ISO C/C++ can't pass in array type as a function argument. As a result, the type buffer automatically casts to char* here. Further, the function signature is different from its implementation, which use char* buffer instead. I see that you do enforce length checking in implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From xliu at openjdk.java.net Thu May 6 19:32:55 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 19:32:55 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> On Thu, 6 May 2021 12:00:21 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > 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: > > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix src/hotspot/share/logging/logDecorations.cpp line 74: > 72: } > 73: > 74: void LogDecorations::print_decoration(LogDecorators::Decorator decorator, outputStream* st) const { Is that a good idea to do a sanity check here in debug build? In my understanding, calling `print_#name##decoration()` for a decorator which was not set in ctor's decorators is undefined. Currently, your code is safe because you carefully initialize each member variable in initializer list. You can't assume follower programmers do the same. If you save the variable `decorators`(a bitmask), you can do sanity check here. This can be done in debug build. eg. `assert(_decorators.is_decorator(decorator), "sanity check");` ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Thu May 6 19:39:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 19:39:58 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 19:17:29 GMT, Xin Liu 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 seven additional commits since the last revision: >> >> - Merge >> - remove harfbuzz fix >> - Remove duplicate coding in gtest >> - gtest for os.iso8601_time should use utc >> - Build fix for Harfbuzz >> - Merge >> - start > > src/hotspot/share/runtime/os.hpp line 231: > >> 229: // E.g., YYYY-MM-DDThh:mm:ss.mmm+zzzz. >> 230: // Returns buffer, or NULL if it failed. >> 231: static char* iso8601_time(jlong milliseconds_since_19700101, char buffer[29], > > You are supposed to get a compiler warning on this char buffer[29]. ISO C/C++ can't pass in array type as a function argument. As a result, the type buffer automatically casts to char* here. > > Further, the function signature is different from its implementation, which use char* buffer instead. > I see that you do enforce length checking in implementation. Oh, good catch, this is a stray edit I thought I reverted. See below. > ISO C/C++ can't pass in array type as a function argument. As a result, the type buffer automatically casts to char* here. No, it can, that's totally fine. It gets automatically translated to pointer type, but its a valid expression nonetheless. It is usually done to indicate that a function expects an output array of a particular length instead of letting the caller guess the right length - and letting him to deal with truncation if he guesses wrong. I originally planned to define the function as iso8601_time(jlong milliseconds_since_19700101, char buffer[29]); to indicate that the only output value length which makes sense is 29, but then I refrained because I wanted to keep the patch simple. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Thu May 6 19:50:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 19:50:02 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> References: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> Message-ID: On Thu, 6 May 2021 19:23:22 GMT, Xin Liu 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 six additional commits since the last revision: >> >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > src/hotspot/share/logging/logDecorations.cpp line 74: > >> 72: } >> 73: >> 74: void LogDecorations::print_decoration(LogDecorators::Decorator decorator, outputStream* st) const { > > Is that a good idea to do a sanity check here in debug build? > > In my understanding, calling `print_#name##decoration()` for a decorator which was not set in ctor's decorators is undefined. Currently, your code is safe because you carefully initialize each member variable in initializer list. You can't assume follower programmers do the same. > > If you save the variable `decorators`(a bitmask), you can do sanity check here. This can be done in debug build. eg. > `assert(_decorators.is_decorator(decorator), "sanity check");` Hmm, would not the compiler warn you if you leave member initialization out? Your idea is not bad, but I usually avoid adding debug only members because you end up with different memory size and layout of data structures between debug and opt builds, which may have strange consequences when hunting bugs. Idk. I can do this here, I have no strong feelings either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From minqi at openjdk.java.net Thu May 6 19:51:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 19:51:20 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v4] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Removed using temporary file in test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/83478dd1..e3363915 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=02-03 Stats: 17 lines in 1 file changed: 2 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From xliu at openjdk.java.net Thu May 6 19:54:54 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 19:54:54 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 19:36:49 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.hpp line 231: >> >>> 229: // E.g., YYYY-MM-DDThh:mm:ss.mmm+zzzz. >>> 230: // Returns buffer, or NULL if it failed. >>> 231: static char* iso8601_time(jlong milliseconds_since_19700101, char buffer[29], >> >> You are supposed to get a compiler warning on this char buffer[29]. ISO C/C++ can't pass in array type as a function argument. As a result, the type buffer automatically casts to char* here. >> >> Further, the function signature is different from its implementation, which use char* buffer instead. >> I see that you do enforce length checking in implementation. > > Oh, good catch, this is a stray edit I thought I reverted. See below. > >> ISO C/C++ can't pass in array type as a function argument. As a result, the type buffer automatically casts to char* here. > > No, it can, that's totally fine. It gets automatically translated to pointer type, but its a valid expression nonetheless. > > It is usually done to indicate that a function expects an output array of a particular length instead of letting the caller guess the right length - and letting him to deal with truncation if he guesses wrong. > > I originally planned to define the function as > > iso8601_time(jlong milliseconds_since_19700101, char buffer[29]); > > to indicate that the only output value length which makes sense is 29, but then I refrained because I wanted to keep the patch simple. C/C++ allow you to write code like that, but they won't check the length of argument <=29 for you. I think you sanity check inside of iso8601_time() is good enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From hseigel at openjdk.java.net Thu May 6 20:00:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 6 May 2021 20:00:52 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 17:40:27 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Additional changes may be needed to these hotspot files that contain ACC_STRICT: cpu/x86/templateTable_x86.cpp: __ testl(rcx, JVM_ACC_STRICT); cpu/x86/templateTable_x86.cpp: __ testl(rcx, JVM_ACC_STRICT); share/ci/ciFlags.hpp: bool is_strict () const { return (_flags & JVM_ACC_STRICT ) != 0; } share/include/jvm_constants.h: JVM_ACC_STRICT | \ share/utilities/accessFlags.hpp: bool is_strict () const { return (_flags & JVM_ACC_STRICT ) != 0; } Also, there are multiple hotspot tests that contain ACC_STRICT. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From shade at openjdk.java.net Thu May 6 20:37:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 20:37:52 GMT Subject: Integrated: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels In-Reply-To: References: Message-ID: <49Dr4o0YQBq13lMlYDY0bQGjUq0-CDYRmZVudK8w_f0=.f88e8b6b-36e5-4212-b922-e9fe171c1b86@github.com> On Fri, 9 Apr 2021 13:09:36 GMT, Aleksey Shipilev wrote: > See the bug report for details. On some kernels, we have trouble parsing madvise tags from `/proc/smaps`. > > Additional testing: > - [x] Test with kernel 5.4.0 (still passes) > - [x] Test with kernel 4.9.0 (used to fail, now passes) > - [x] Test with kernel 4.15 (still passes) > - [x] Test with kernel 4.14.17 (used to fail, now passes) This pull request has now been integrated. Changeset: 36e5ad61 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/36e5ad61e63e2f1da9cf565c607db28f23622ea9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8263236: runtime/os/TestTracePageSizes.java fails on old kernels Reviewed-by: dholmes, sjohanss, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3415 From xliu at openjdk.java.net Thu May 6 21:27:52 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 6 May 2021 21:27:52 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> Message-ID: On Thu, 6 May 2021 19:47:08 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logDecorations.cpp line 74: >> >>> 72: } >>> 73: >>> 74: void LogDecorations::print_decoration(LogDecorators::Decorator decorator, outputStream* st) const { >> >> Is that a good idea to do a sanity check here in debug build? >> >> In my understanding, calling `print_#name##decoration()` for a decorator which was not set in ctor's decorators is undefined. Currently, your code is safe because you carefully initialize each member variable in initializer list. You can't assume follower programmers do the same. >> >> If you save the variable `decorators`(a bitmask), you can do sanity check here. This can be done in debug build. eg. >> `assert(_decorators.is_decorator(decorator), "sanity check");` > > Hmm, would not the compiler warn you if you leave member initialization out? > > Your idea is not bad, but I usually avoid adding debug only members because you end up with different memory size and layout of data structures between debug and opt builds, which may have strange consequences when hunting bugs. > > Idk. I can do this here, I have no strong feelings either way. C++ won't warn you if you don't initialize member variables. Unlike Java, C++ even doesn't zero them for you by default. eg. #include class T{ public: int a, b, c; T() : b(0) {} }; int main() { T t; printf("%d\n", t.a); // random value on stack printf("%d\n", t.b); // 0 printf("%d\n", t.c); // random value on stack } It's relatively safe now because all member variables you added to LogDecorations are "scalars". If we extend an object decorator, printing an uninitialized object may result in undefined behavior. I am fine with/without it. can leave it to the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From minqi at openjdk.java.net Thu May 6 21:37:35 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 6 May 2021 21:37:35 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove tab space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3886/files - new: https://git.openjdk.java.net/jdk/pull/3886/files/e3363915..ab43e478 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3886&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3886/head:pull/3886 PR: https://git.openjdk.java.net/jdk/pull/3886 From iklam at openjdk.java.net Thu May 6 22:02:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 6 May 2021 22:02:52 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space The latest version LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3886 From coleenp at openjdk.java.net Thu May 6 22:57:01 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 6 May 2021 22:57:01 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:18:16 GMT, Claes Redestad wrote: >> This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. >> >> Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. >> >> Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > assert that vmIntrinsics::_dsqrt are only selected for Math/StrictMath::sqrt Ok with some minor nits and questions. src/hotspot/share/interpreter/abstractInterpreter.cpp line 125: > 123: > 124: #ifndef ZERO > 125: switch (m->intrinsic_id()) { Can this just be switch (id) since you fetched m->intrinsic_id() above? src/hotspot/share/interpreter/abstractInterpreter.cpp line 136: > 134: case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits; > 135: case vmIntrinsics::_longBitsToDouble: return java_lang_Double_longBitsToDouble; > 136: case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits; Could you align these return statements? src/hotspot/share/interpreter/abstractInterpreter.cpp line 137: > 135: case vmIntrinsics::_longBitsToDouble: return java_lang_Double_longBitsToDouble; > 136: case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits; > 137: case vmIntrinsics::_dsin: return java_lang_math_sin; So ZERO doesn't have these? src/hotspot/share/interpreter/abstractInterpreter.cpp line 142: > 140: // Native method? > 141: // Note: This test must come _before_ the test for intrinsic > 142: // methods. See also comments below. So apparently this is no longer true? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3798 From redestad at openjdk.java.net Thu May 6 23:38:58 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 6 May 2021 23:38:58 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v3] In-Reply-To: References: Message-ID: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Review comments - Merge branch 'master' into method_kind - assert that vmIntrinsics::_dsqrt are only selected for Math/StrictMath::sqrt - Improve comment - Select native as the kind for StrictMath::sqrt - Streamline AbstractInterpreter::method_kind ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3798/files - new: https://git.openjdk.java.net/jdk/pull/3798/files/4e616b33..bb781718 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=01-02 Stats: 26769 lines in 625 files changed: 15562 ins; 6174 del; 5033 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From redestad at openjdk.java.net Thu May 6 23:39:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 6 May 2021 23:39:00 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 22:45:28 GMT, Coleen Phillimore wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> assert that vmIntrinsics::_dsqrt are only selected for Math/StrictMath::sqrt > > src/hotspot/share/interpreter/abstractInterpreter.cpp line 125: > >> 123: >> 124: #ifndef ZERO >> 125: switch (m->intrinsic_id()) { > > Can this just be switch (id) since you fetched m->intrinsic_id() above? Yes, or maybe `iid` is a better name for that variable. > src/hotspot/share/interpreter/abstractInterpreter.cpp line 136: > >> 134: case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits; >> 135: case vmIntrinsics::_longBitsToDouble: return java_lang_Double_longBitsToDouble; >> 136: case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits; > > Could you align these return statements? Ok, I'll try tidying up - is there some rule of thumb on how to align in a switch like this where the longest case label is.. pretty long? > src/hotspot/share/interpreter/abstractInterpreter.cpp line 137: > >> 135: case vmIntrinsics::_longBitsToDouble: return java_lang_Double_longBitsToDouble; >> 136: case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits; >> 137: case vmIntrinsics::_dsin: return java_lang_math_sin; > > So ZERO doesn't have these? Hmm, I looked at the math intrinsics, which are all unimplemented in zero. I see now that there are some intrinsics implemented in ZERO, so I'll take the conservative route and move the `#ifndef` to only exclude such cases as were excluded before. ------------- PR: https://git.openjdk.java.net/jdk/pull/3798 From redestad at openjdk.java.net Thu May 6 23:39:04 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 6 May 2021 23:39:04 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 22:53:32 GMT, Coleen Phillimore wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Review comments >> - Merge branch 'master' into method_kind >> - assert that vmIntrinsics::_dsqrt are only selected for Math/StrictMath::sqrt >> - Improve comment >> - Select native as the kind for StrictMath::sqrt >> - Streamline AbstractInterpreter::method_kind > > src/hotspot/share/interpreter/abstractInterpreter.cpp line 142: > >> 140: // Native method? >> 141: // Note: This test must come _before_ the test for intrinsic >> 142: // methods. See also comments below. > > So apparently this is no longer true? The one case of a native and intrinsic method is StrictMath::sqrt, which is handles specially above to retain the order of precedence. ------------- PR: https://git.openjdk.java.net/jdk/pull/3798 From minqi at openjdk.java.net Fri May 7 00:07:11 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 00:07:11 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 23:59:21 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tab space > > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: > >> 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); >> 77: setKeepArchive(true); >> 78: outputDirFile.setWritable(true); > > Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) The comment is for the testing item --- that is consistent with println contents. The first set 'true' is for get the archive and keep the archive, the real test is after set it to 'false', the test will fail and we check the previous archive still available. > test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 89: > >> 87: outputDirFile.setWritable(false); >> 88: test(localFileName, pid, noBoot, EXPECT_FAIL); >> 89: outputDirFile.setWritable(true); > > Would the test fail without setting the dir not writable at line 87? See reply above. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:07:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:07:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space I have 2 questions on the test. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: > 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); > 77: setKeepArchive(true); > 78: outputDirFile.setWritable(true); Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 89: > 87: outputDirFile.setWritable(false); > 88: test(localFileName, pid, noBoot, EXPECT_FAIL); > 89: outputDirFile.setWritable(true); Would the test fail without setting the dir not writable at line 87? ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:12:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:12:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:02:56 GMT, Yumin Qi wrote: >> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78: >> >>> 76: print2ln(test_count++ + " Set target dir not writable, do dynamic dump"); >>> 77: setKeepArchive(true); >>> 78: outputDirFile.setWritable(true); >> >> Should the comment be `// Set target dir writable ...` ? (since you're setting the dir to writable at line 78) > > The comment is for the testing item --- that is consistent with println contents. > The first set 'true' is for get the archive and keep the archive, the real test is after set it to 'false', the test will fail and we check the previous archive still available. I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From ccheung at openjdk.java.net Fri May 7 00:12:09 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 00:12:09 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote: >> Hi, Please review >> When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. >> The newly added test case skipped testing on Windows since File operation result is not same as on Linux. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove tab space Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Fri May 7 00:15:17 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 00:15:17 GMT Subject: RFR: 8265465: jcmd VM.cds should keep already dumped archive when exceptions happens [v5] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 21:59:32 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tab space > > The latest version LGTM @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From whuang at openjdk.java.net Fri May 7 01:49:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 7 May 2021 01:49:00 GMT Subject: RFR: 8264760: JVM crashes when two threads encounter the same resolution error [v7] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 13:03:23 GMT, Harold Seigel wrote: > Changes look good. Thanks for fixing this. > Harold Thank you for your approval. @dholmes-ora @hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From minqi at openjdk.java.net Fri May 7 03:04:57 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 03:04:57 GMT Subject: Integrated: 8265465: jcmd VM.cds should keep already dumped archive when exception happens In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:10:21 GMT, Yumin Qi wrote: > Hi, Please review > When using jcmd to dump shared archive, if the archive name exists, it will be deleted first. If exception happens during dumping process, there is no new archive created. This PR changes to first dump the archive with a temporary file name. With successful dump, the temporary file will be rename to its given name. This way the old archive will not be touched on exception. > The newly added test case skipped testing on Windows since File operation result is not same as on Linux. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: 43ad24fe Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/43ad24feb20ed2007922472a15873e1094147b0d Stats: 169 lines in 4 files changed: 132 ins; 4 del; 33 mod 8265465: jcmd VM.cds should keep already dumped archive when exception happens Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3886 From minqi at openjdk.java.net Fri May 7 04:00:15 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 04:00:15 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing Message-ID: Hi, Please review In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. Tests: tier1,tier2 Thanks Yumin ------------- Commit messages: - 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing Changes: https://git.openjdk.java.net/jdk/pull/3910/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3910&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266576 Stats: 14 lines in 2 files changed: 9 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3910.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3910/head:pull/3910 PR: https://git.openjdk.java.net/jdk/pull/3910 From darcy at openjdk.java.net Fri May 7 04:58:22 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 7 May 2021 04:58:22 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8266530 - Respond to review feedback. - 8266530: HotSpot changes for JEP 306 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/bef3958f..f610ba6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=01-02 Stats: 21775 lines in 455 files changed: 12306 ins; 5030 del; 4439 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From dholmes at openjdk.java.net Fri May 7 05:39:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 7 May 2021 05:39:12 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" Message-ID: If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. @coleenp also contributed to an earlier version of the fix. Thanks to both Coleen and Ioi for their insights, discussions and contributions. Testing: - the new test - tiers 1-3 Thanks, David ------------- Commit messages: - Fix typo - Completely simpified the has_nest_member check to only use names. - Add test - Tweak logging message - 8261395: C1 crash "cannot make java calls from the native compiler" - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. Changes: https://git.openjdk.java.net/jdk/pull/3913/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3913&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261395 Stats: 246 lines in 4 files changed: 184 ins; 40 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/3913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3913/head:pull/3913 PR: https://git.openjdk.java.net/jdk/pull/3913 From stuefe at openjdk.java.net Fri May 7 05:42:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 05:42:51 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> Message-ID: On Thu, 6 May 2021 21:24:56 GMT, Xin Liu wrote: >> Hmm, would not the compiler warn you if you leave member initialization out? >> >> Your idea is not bad, but I usually avoid adding debug only members because you end up with different memory size and layout of data structures between debug and opt builds, which may have strange consequences when hunting bugs. >> >> Idk. I can do this here, I have no strong feelings either way. > > C++ won't warn you if you don't initialize member variables. Unlike Java, C++ even doesn't zero them for you by default. > > eg. > > #include > class T{ > public: > int a, b, c; > T() : b(0) {} > }; > > int main() { > T t; > printf("%d\n", t.a); // random value on stack > printf("%d\n", t.b); // 0 > printf("%d\n", t.c); // random value on stack > } > > > It's relatively safe now because all member variables you added to LogDecorations are "scalars". If we extend an object decorator, printing an uninitialized object may result in undefined behavior. > > I am fine with/without it. can leave it to the future. Okay, I'll add the check ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 05:42:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 05:42:51 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: <4Tqm0B8-9KAFZwPEqS-LLYZZ1qMWsjIGS9K4Y1C1Cs8=.c07323a4-8b8d-4410-bd18-da1e1b0ca379@github.com> Message-ID: On Fri, 7 May 2021 05:39:06 GMT, Thomas Stuefe wrote: >> C++ won't warn you if you don't initialize member variables. Unlike Java, C++ even doesn't zero them for you by default. >> >> eg. >> >> #include >> class T{ >> public: >> int a, b, c; >> T() : b(0) {} >> }; >> >> int main() { >> T t; >> printf("%d\n", t.a); // random value on stack >> printf("%d\n", t.b); // 0 >> printf("%d\n", t.c); // random value on stack >> } >> >> >> It's relatively safe now because all member variables you added to LogDecorations are "scalars". If we extend an object decorator, printing an uninitialized object may result in undefined behavior. >> >> I am fine with/without it. can leave it to the future. > > Okay, I'll add the check (I think static checkers like Sonarcloud would pick those simple errors up) ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 06:11:22 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 06:11:22 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v4] In-Reply-To: References: Message-ID: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedback yasumasa and xin ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3869/files - new: https://git.openjdk.java.net/jdk/pull/3869/files/40f23a23..e6461c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=02-03 Stats: 9 lines in 4 files changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3869/head:pull/3869 PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Fri May 7 06:11:22 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 06:11:22 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v4] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:58:49 GMT, Xin Liu wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback yasumasa and xin > > The API change looks good to me. I understand that this is prerequisite of your logdecoration change. make sense. > > I don't understand your change in harfbuzz header. Thanks @navyxliu and @simonis and @YaSuenag for your reviews. Last change: - fixes the stray edit in the prototype Xin noted - adds an explicit constant for the output buffer size of iso timestamps @YaSuenag could you please officially approve this PR? Unfortunately, Xin is no committer yet, so I need a second reviewer. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From iklam at openjdk.java.net Fri May 7 06:18:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 7 May 2021 06:18:57 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David LGTM. Just a suggestion for an assert. src/hotspot/share/oops/instanceKlass.cpp line 166: > 164: // We know that k is an instance class in the same package and hence the > 165: // same classloader. > 166: bool InstanceKlass::has_nest_member(InstanceKlass* k, JavaThread* current) const { Should we add an assert that "k is an instance class in the same package and hence the same classloader" ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3913 From stuefe at openjdk.java.net Fri May 7 06:20:19 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 06:20:19 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 19:06:30 GMT, Xin Liu 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 six additional commits since the last revision: >> >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > src/hotspot/share/logging/logTagSet.hpp line 116: > >> 114: >> 115: void label(outputStream* st, const char* separator = ",") const; >> 116: int label(char *buf, size_t len, const char* separator = ",") const; > > This old label() is only used in LogTagset. You can make it private. > > Further, no one consumes its return value now. you can change its return type to void. It will avoid different return types for overloaded member functions. I thought so too, but the gtests still test this interface. Seeing that its not used in the hs codebase anymore I could remove it, but would have to rewrite all gtests to use the new interface instead. I'd rather avoid this to keep the patch small. Lets do this in a different RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From ddong at openjdk.java.net Fri May 7 06:27:25 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 7 May 2021 06:27:25 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: minor adjustment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/a552ea69..8d500a84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From xliu at openjdk.java.net Fri May 7 06:37:53 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 7 May 2021 06:37:53 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:17:02 GMT, Thomas Stuefe wrote: >> src/hotspot/share/logging/logTagSet.hpp line 116: >> >>> 114: >>> 115: void label(outputStream* st, const char* separator = ",") const; >>> 116: int label(char *buf, size_t len, const char* separator = ",") const; >> >> This old label() is only used in LogTagset. You can make it private. >> >> Further, no one consumes its return value now. you can change its return type to void. It will avoid different return types for overloaded member functions. > > I thought so too, but the gtests still test this interface. Seeing that its not used in the hs codebase anymore I could remove it, but would have to rewrite all gtests to use the new interface instead. I'd rather avoid this to keep the patch small. Lets do this in a different RFE. understood. fair enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From dholmes at openjdk.java.net Fri May 7 06:38:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 7 May 2021 06:38:57 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:15:10 GMT, Ioi Lam wrote: >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > src/hotspot/share/oops/instanceKlass.cpp line 166: > >> 164: // We know that k is an instance class in the same package and hence the >> 165: // same classloader. >> 166: bool InstanceKlass::has_nest_member(InstanceKlass* k, JavaThread* current) const { > > Should we add an assert that "k is an instance class in the same package and hence the same classloader" I don't think we need to given there is only a single caller of this method and it happens after those very checks: if (is_same_class_package(k)) { // Now check actual membership. We can't be a member if our "host" is // not an instance class. if (k->is_instance_klass()) { nest_host_k = InstanceKlass::cast(k); bool is_member = nest_host_k->has_nest_member(this, current); ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From stuefe at openjdk.java.net Fri May 7 06:45:20 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 06:45:20 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v3] In-Reply-To: References: Message-ID: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Xins debug check proposal - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3874/files - new: https://git.openjdk.java.net/jdk/pull/3874/files/3a357557..9bffd4f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=01-02 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3874/head:pull/3874 PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 06:45:24 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 06:45:24 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 12:00:21 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > 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: > > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix @navyxliu @simonis @YaSuenag Thanks for your feedbacks! Latest iteration: - changed help text printing to use the new `LogTagSet::label(outputStream)` interface - added Xin's proposal of a debug check testing if someone prints an uninitialized decorator value. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From ysuenaga at openjdk.java.net Fri May 7 06:51:59 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 7 May 2021 06:51:59 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v4] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:11:22 GMT, Thomas Stuefe wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback yasumasa and xin Looks good! I think `needed_buffer` in `os::iso8601_time()` is no longer needed, but it's ok if it is left. ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3869 From ysuenaga at openjdk.java.net Fri May 7 06:58:55 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 7 May 2021 06:58:55 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:45:20 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Xins debug check proposal > - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying I just approved #3869, so I hope to use `os::iso8601_timestamp_size` in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 07:11:28 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 07:11:28 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v5] In-Reply-To: References: Message-ID: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - remove stray edit - Yasumasa-feedback-2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3869/files - new: https://git.openjdk.java.net/jdk/pull/3869/files/e6461c58..2b6e20f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3869&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3869/head:pull/3869 PR: https://git.openjdk.java.net/jdk/pull/3869 From ysuenaga at openjdk.java.net Fri May 7 07:11:31 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 7 May 2021 07:11:31 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v5] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 07:07:54 GMT, Thomas Stuefe wrote: >> We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. >> >> This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) >> >> This patch provides an additional API: >> `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` >> alongside the existing >> `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` >> and implements the latter using the former. Not much code added. >> >> In addition, it adds a regression gtest for these APIs. >> >> Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. >> >> Testing: GHA, manual gtests, SAP nightlies on all our platforms. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - remove stray edit > - Yasumasa-feedback-2 Thank you for fixing it! It still looks good. ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Fri May 7 07:11:32 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 07:11:32 GMT Subject: RFR: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps [v4] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:49:14 GMT, Yasumasa Suenaga wrote: > Looks good! > I think `needed_buffer` in `os::iso8601_time()` is no longer needed, but it's ok if it is left. Thanks Yasumasa! I changed the code a bit and removed needed_buffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From xliu at openjdk.java.net Fri May 7 07:46:51 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 7 May 2021 07:46:51 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:45:20 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Xins debug check proposal > - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying I guess you will revert code change of JDK-8266536. For other parts in this patch, LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 07:59:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 07:59:54 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v3] In-Reply-To: References: Message-ID: <33CQPfLQXiS0-olHcQBvGEfx74yb7Rmde4tfGAaPcE4=.af28ad0a-3c18-480a-bfde-17561f07d21e@github.com> On Fri, 7 May 2021 07:43:34 GMT, Xin Liu wrote: > I guess you will revert code change of JDK-8266536. Sure > For other parts in this patch, LGTM. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From redestad at openjdk.java.net Fri May 7 09:27:15 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 7 May 2021 09:27:15 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v4] In-Reply-To: References: Message-ID: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix mismatched endifs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3798/files - new: https://git.openjdk.java.net/jdk/pull/3798/files/bb781718..04af49d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From stuefe at openjdk.java.net Fri May 7 09:50:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 09:50:51 GMT Subject: Integrated: JDK-8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps In-Reply-To: References: Message-ID: On Wed, 5 May 2021 04:31:57 GMT, Thomas Stuefe wrote: > We have os::iso8601_time(), which gives an ISO8601 timestamp of the current time. It would be very useful to have a second variant which can be fed an arbitrary numerical timestamp. > > This is useful in the context of making asynchronous UL logging cheaper (see JDK-8229517) > > This patch provides an additional API: > `char* os::iso8601_time(jlong milliseconds_since_19700101, char* buffer, size_t buffer_length, bool utc);` > alongside the existing > `char* os::iso8601_time(char* buffer, size_t buffer_length, bool utc);` > and implements the latter using the former. Not much code added. > > In addition, it adds a regression gtest for these APIs. > > Please ignore the harfbuzz change, its a build fix needed for older gcc, will be removed before final push. > > Testing: GHA, manual gtests, SAP nightlies on all our platforms. > > Thanks, Thomas This pull request has now been integrated. Changeset: 94c6177f Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/94c6177f246fc569b416f85f1411f7fe031f7aaf Stats: 81 lines in 4 files changed: 72 ins; 6 del; 3 mod 8266536: Provide a variant of os::iso8601_time which works with arbitrary timestamps Reviewed-by: xliu, simonis, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/3869 From stuefe at openjdk.java.net Fri May 7 10:21:10 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 10:21:10 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v4] In-Reply-To: References: Message-ID: <9OsCIqtSeKwYPgVz6zh34EUKObMrmws8e0BEa7qFqro=.67fe77a6-48e2-4002-94d1-b1465ac6d7a1@github.com> > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge - Xins debug check proposal - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying - Merge - Remove harfbuzz build fix - Volker feedback - start - cherry-picked JDK-8266536 - harfbuzz-buildfix ------------- Changes: https://git.openjdk.java.net/jdk/pull/3874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=03 Stats: 169 lines in 7 files changed: 64 ins; 34 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/3874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3874/head:pull/3874 PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 10:21:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 10:21:11 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v4] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 09:40:42 GMT, Volker Simonis wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge >> - Xins debug check proposal >> - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying >> - Merge >> - Remove harfbuzz build fix >> - Volker feedback >> - start >> - cherry-picked JDK-8266536 >> - harfbuzz-buildfix > > Hi Thomas, > > your change looks good and I like it :) > > Am I right that you've changed the 256-char-for-all-decorators limit to a 255-char limit for a single decorator (which is obviously much better)? > > Find my other comments inline. > > Thank you and best regards, > Volker @simonis : if you approve, I will push. All nightlies at SAP ran through fine. ..thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From dholmes at openjdk.java.net Fri May 7 10:47:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 7 May 2021 10:47:57 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Hi Joe, I don't really understand the proposed changes. If strictfp is implied to always be true that is fine, but if the ACC_STRICT modifier is applied then I don't see how it makes sense to allow it suddenly appear in places where it is not currently allowed. And if ACC_STRICT is to be undefined then I don't see how these changes suffice. ?? David src/hotspot/share/classfile/classFileParser.cpp line 4801: > 4799: // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as > 4800: // those flags are illegal irrespective of ACC_ABSTRACT being set or not. > 4801: (is_abstract && (is_private || is_static || (!major_gte_17 && is_strict)))) { I'm not sure it makes sense to allow ACC_STRICT to suddenly appear where it would otherwise be illegal. ?? test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpIntMethod60.jcod line 24: > 22: */ > 23: > 24: // Code below is equivalent to: If it is equivalent why do we need the jcod file? Presumably there is something here that differs from what the Java source would produce. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From simonis at openjdk.java.net Fri May 7 11:00:04 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 7 May 2021 11:00:04 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v4] In-Reply-To: <9OsCIqtSeKwYPgVz6zh34EUKObMrmws8e0BEa7qFqro=.67fe77a6-48e2-4002-94d1-b1465ac6d7a1@github.com> References: <9OsCIqtSeKwYPgVz6zh34EUKObMrmws8e0BEa7qFqro=.67fe77a6-48e2-4002-94d1-b1465ac6d7a1@github.com> Message-ID: <8FGJcHO5NTAWEPpu7HibFNU_4cyaD-klNP62P45BQmQ=.441337b3-3234-40fb-860c-1359d60a4438@github.com> On Fri, 7 May 2021 10:21:10 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge > - Xins debug check proposal > - LogTagSet::describe_tagsets can use the stream interface of label and avoid copying > - Merge > - Remove harfbuzz build fix > - Volker feedback > - start > - cherry-picked JDK-8266536 > - harfbuzz-buildfix Hi Thomas, everything looks fine now except the comments below (i.e. didn't you wanted to use the new `iso8601_timestamp_size`?). If that 's clarified I'll approve this PR. Thanks, Volker src/hotspot/share/logging/logDecorations.cpp line 94: > 92: > 93: void LogDecorations::print_time_decoration(outputStream* st) const { > 94: char buf[29]; Didn't you wanted to use the new `iso8601_timestamp_size` constant here? src/hotspot/share/logging/logDecorations.cpp line 100: > 98: > 99: void LogDecorations::print_utctime_decoration(outputStream* st) const { > 100: char buf[29]; Didn't you wanted to use the new `iso8601_timestamp_size` constant here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From dholmes at openjdk.java.net Fri May 7 11:08:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 7 May 2021 11:08:53 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > Hi, Please review > > In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > Tests: tier1,tier2 > > Thanks > Yumin Hi Yumin, So there are three "exit" paths covered by this: - System.exit/halt - last thread terminates VM - -Xshare:dump so that seems reasonable. But I see a pre-existing problem that is now worse with this change. In JavaThread::invoke_shutdown_hooks we have this code: // We could get here with a pending exception, if so clear it now. if (this->has_pending_exception()) { this->clear_pending_exception(); } but that appears after the call to link_and_cleanup_shared_classes, so if in fact there is a pre-existing exception we will return from link_and_cleanup_shared_classes at the first CHECK (which is now on the newly moved code). In order to get the current crashes fixed we can address the exception issue in a follow up bug. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3910 From david.holmes at oracle.com Fri May 7 11:14:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 May 2021 21:14:03 +1000 Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> <1570590060.24715.1620259020879.JavaMail.zimbra@u-pem.fr> Message-ID: On 6/05/2021 10:14 am, Joe Darcy wrote: > On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote: >> Given that its value 0x800 is not used on other members, it can be >> reused to indicate something on class/field/method. >> So we may want to recycle it >> ?? undefined -> defined -> undefined -> defined > > > Yes; the intention of undefining it now is to allow the possibility of > the flag position being assigned to another purpose in the future for > later class file versions. I don't think we can reasonably attempt to do this in the short to medium term. The basic proposal is that ACC_STRICT becomes implied from this point forward and javac will stop generating it. But the existing rules for ACC_STRICT should remain as it is now technically "deprecated". Eventually we should reject classfiles >=17 that explicitly set ACC_STRICT. Then some time after that we could recycle the ACC_STRICT bit value to use for another flag. Without a period where we reject the ACC_STRICT bit I think it would be dangerous to suddenly interpret its presence as ACC_SOMETHING_NEW. Cheers, David ----- > -Joe > From forax at univ-mlv.fr Fri May 7 11:45:27 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 7 May 2021 13:45:27 +0200 (CEST) Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> <1cb69882-d325-f999-4917-2a3b27beec1d@oracle.com> <1570590060.24715.1620259020879.JavaMail.zimbra@u-pem.fr> Message-ID: <936885134.1026147.1620387927525.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "joe darcy" , "Remi Forax" > Cc: "Joe Darcy" , "hotspot-runtime-dev" > Envoy?: Vendredi 7 Mai 2021 13:14:03 > Objet: Re: RFR: 8266530: HotSpot changes for JEP 306 > On 6/05/2021 10:14 am, Joe Darcy wrote: >> On 5/5/2021 4:57 PM, forax at univ-mlv.fr wrote: >>> Given that its value 0x800 is not used on other members, it can be >>> reused to indicate something on class/field/method. >>> So we may want to recycle it >>> ?? undefined -> defined -> undefined -> defined >> >> >> Yes; the intention of undefining it now is to allow the possibility of >> the flag position being assigned to another purpose in the future for >> later class file versions. > > I don't think we can reasonably attempt to do this in the short to > medium term. The basic proposal is that ACC_STRICT becomes implied from > this point forward and javac will stop generating it. But the existing > rules for ACC_STRICT should remain as it is now technically > "deprecated". Eventually we should reject classfiles >=17 that > explicitly set ACC_STRICT. Then some time after that we could recycle > the ACC_STRICT bit value to use for another flag. > > Without a period where we reject the ACC_STRICT bit I think it would be > dangerous to suddenly interpret its presence as ACC_SOMETHING_NEW. yes, given that javac already does not use ACC_STRICT for classfiles version >= 17, the VM should reject usage of ACC_STRICT now, so ACC_SOMETHING_NEW can be introduced later. Otherwise we may have ASM visitors that uses ACC_STRICT believing it's the old semantics but in fact it's the new semantics. > > Cheers, > David > ----- > >> -Joe R?mi From stuefe at openjdk.java.net Fri May 7 12:18:59 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 12:18:59 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v4] In-Reply-To: <8FGJcHO5NTAWEPpu7HibFNU_4cyaD-klNP62P45BQmQ=.441337b3-3234-40fb-860c-1359d60a4438@github.com> References: <9OsCIqtSeKwYPgVz6zh34EUKObMrmws8e0BEa7qFqro=.67fe77a6-48e2-4002-94d1-b1465ac6d7a1@github.com> <8FGJcHO5NTAWEPpu7HibFNU_4cyaD-klNP62P45BQmQ=.441337b3-3234-40fb-860c-1359d60a4438@github.com> Message-ID: On Fri, 7 May 2021 10:56:30 GMT, Volker Simonis wrote: > Hi Thomas, > > everything looks fine now except the comments below (i.e. didn't you wanted to use the new `iso8601_timestamp_size`?). > > If that 's clarified I'll approve this PR. > > Thanks, > Volker Hi Volker, thanks! Yes, I missed that, will change it before pushing. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 12:40:24 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 12:40:24 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v5] In-Reply-To: References: Message-ID: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: use iso8601_timestamp_size instead of 29 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3874/files - new: https://git.openjdk.java.net/jdk/pull/3874/files/ba8db63c..6aac5c85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3874&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3874/head:pull/3874 PR: https://git.openjdk.java.net/jdk/pull/3874 From stuefe at openjdk.java.net Fri May 7 12:42:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 12:42:52 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v4] In-Reply-To: References: <9OsCIqtSeKwYPgVz6zh34EUKObMrmws8e0BEa7qFqro=.67fe77a6-48e2-4002-94d1-b1465ac6d7a1@github.com> <8FGJcHO5NTAWEPpu7HibFNU_4cyaD-klNP62P45BQmQ=.441337b3-3234-40fb-860c-1359d60a4438@github.com> Message-ID: On Fri, 7 May 2021 12:15:42 GMT, Thomas Stuefe wrote: > Hi Thomas, > > everything looks fine now except the comments below (i.e. didn't you wanted to use the new `iso8601_timestamp_size`?). > > If that 's clarified I'll approve this PR. > > Thanks, > Volker @simonis done. You can approve. Has been nice to have you as a Reviewer again ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From whuang at openjdk.java.net Fri May 7 12:58:55 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 7 May 2021 12:58:55 GMT Subject: Integrated: 8264760: JVM crashes when two threads encounter the same resolution error In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 02:43:37 GMT, Wang Huang wrote: > As shown in JDK-8264760, I changed notes with @dholmes-ora and only fixed this issue by deleting the assert. ~~The other whole bigger issue will be fixed in the other issue.~~ This pull request has now been integrated. Changeset: 9a19a0cc Author: Wang Huang Committer: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/9a19a0cc1087311b01c5c15432c4451f1ea24fad Stats: 285 lines in 4 files changed: 283 ins; 0 del; 2 mod 8264760: JVM crashes when two threads encounter the same resolution error Co-authored-by: Wang Huang Co-authored-by: Wu Yan Reviewed-by: dholmes, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3392 From simonis at openjdk.java.net Fri May 7 13:18:52 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 7 May 2021 13:18:52 GMT Subject: RFR: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size [v5] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 12:40:24 GMT, Thomas Stuefe wrote: >> This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. >> >> As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). >> >> As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. >> >> What the patch does: >> >> In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. >> >> So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. >> >> *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* >> >> Testing: >> - gtests, manually >> - jtreg runtime/logging, manually >> - SAP nightlies ran fine, but since then the tests changed, will run them again tonight > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use iso8601_timestamp_size instead of 29 It has been a pleasure :) Approved. ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3874 From dcubed at openjdk.java.net Fri May 7 13:49:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 7 May 2021 13:49:53 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. This is a disturbing statement given the breakage in the CI. Has sufficient testing been done to determine whether these other two bugs continue to happen or not. I'm really starting to wonder why the original fix wasn't backed out on Wednesday. ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From stuefe at openjdk.java.net Fri May 7 14:08:34 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 7 May 2021 14:08:34 GMT Subject: Integrated: JDK-8266503: [UL] Make Decorations safely copy-able and reduce their size In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:09:35 GMT, Thomas Stuefe wrote: > This patch reduces the size of UL `LogDecorations` by about 85% (from 368 -> 56 bytes on Linux x64). This matters in the context of asynchronous logging in UL where we plan to keep a buffer containing log messages, including decorations, for asynchronous printing. > > As a side effect, it makes the LogDecorations object safe to copy with trivial assignment constructors and operators (which it had not been before). > > As another side effect, the 256-char-for-all-decorators limit has been removed with this patch. > > What the patch does: > > In LogDecorations, we resolve the values of the given decorators ("uptime", "tid" etc) and print them in human-readable format. Before this patch, the class LogDecorations stored the printed decorators in an internal (limited, fixed-sized) buffer. This is inefficient since this takes much more memory than storing the binary data before printing them. > > So this patch separates the decorator value resolving from the printing. It stores the resolved values in binary form and only prints them when needed. Since a decorations object is only printed once this is fine. No need to cache the formatted text. > > *Please Note that this patch includes the fix for JDK-8266536: "Provide a variant of os::iso8601_time which works with arbitrary timestamps" which is in a separate PR (https://github.com/openjdk/jdk/pull/3869) - so please ignore all the iso6801 stuff. It also contains a fix for the broken harfbuzz build.* > > Testing: > - gtests, manually > - jtreg runtime/logging, manually > - SAP nightlies ran fine, but since then the tests changed, will run them again tonight This pull request has now been integrated. Changeset: 74fecc07 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/74fecc070a6462e6a2d061525b53a63de15339f9 Stats: 169 lines in 7 files changed: 64 ins; 34 del; 71 mod 8266503: [UL] Make Decorations safely copy-able and reduce their size Reviewed-by: simonis, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/3874 From hseigel at openjdk.java.net Fri May 7 14:08:55 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 7 May 2021 14:08:55 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David LGTM. Thanks for fixing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3913 From minqi at openjdk.java.net Fri May 7 14:55:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 14:55:52 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > Hi, Please review > > In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > Tests: tier1,tier2 > > Thanks > Yumin > > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > This is a disturbing statement given the breakage in the CI. Has sufficient testing > been done to determine whether these other two bugs continue to happen or not. > > I'm really starting to wonder why the original fix wasn't backed out on Wednesday. > Hi Yumin, > > So there are three "exit" paths covered by this: > > * System.exit/halt > * last thread terminates VM > * -Xshare:dump > > so that seems reasonable. > > But I see a pre-existing problem that is now worse with this change. In JavaThread::invoke_shutdown_hooks we have this code: > > // We could get here with a pending exception, if so clear it now. > if (this->has_pending_exception()) { > this->clear_pending_exception(); > } > > but that appears after the call to link_and_cleanup_shared_classes, so if in fact there is a pre-existing exception we will return from link_and_cleanup_shared_classes at the first CHECK (which is now on the newly moved code). > > In order to get the current crashes fixed we can address the exception issue in a follow up bug. > Hi, David Thanks for review. Yes, if the regeneration of holder classes returned with first CHECK, the exception is cleaned here. So the dump will be finished without finishing the original functions which link_and_cleanup_shared_classes intends to do. This requests LambdaFormInvokers::regnerate_holder_classes suppress all exceptions except for OOM (which exit directly from VM). This part needs an overall checking for various cases. Thanks for catching this. Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From minqi at openjdk.java.net Fri May 7 14:58:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 14:58:51 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 14:52:48 GMT, Yumin Qi wrote: > > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > This is a disturbing statement given the breakage in the CI. Has sufficient testing > been done to determine whether these other two bugs continue to happen or not. > > I'm really starting to wonder why the original fix wasn't backed out on Wednesday. Hi, Dan The overnight testing never finished, even part of the tests never got started. I did not back out first since the fix is quick, but did not expect the test take so long. Thanks for the reminding. Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From coleenp at openjdk.java.net Fri May 7 15:20:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 7 May 2021 15:20:53 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David src/hotspot/share/oops/instanceKlass.cpp line 170: > 168: if (_nest_members == NULL || _nest_members == Universe::the_empty_short_array()) { > 169: if (log_is_enabled(Trace, class, nestmates)) { > 170: ResourceMark rm(current); Since THREAD is only used for ResourceMark and HandleMark which don't have to be a JavaThread, this parameter can just be Thread* current. And it should be in the first argument so it's not confused with CHECK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From coleenp at openjdk.java.net Fri May 7 15:27:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 7 May 2021 15:27:50 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: <09g5itqNtWo6j0vjViCHmrDBNQBUWs2_s4E0AlLzmTc=.20dd29fb-1418-4146-a4c3-0b62cb300bf0@github.com> On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David Looks good but I think you should remove the conversion of Thread to JavaThread because it's also going to conflict with your later change. src/hotspot/share/oops/instanceKlass.cpp line 251: > 249: // are idempotent. > 250: InstanceKlass* InstanceKlass::nest_host(TRAPS) { > 251: JavaThread* current = THREAD->as_Java_thread(); I don't see why this is necessary to do this conversion. test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 69: > 67: } > 68: > 69: static byte[] getBytesForClass(String name) throws IOException { There's a ClassUnloadCommon library call for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From minqi at openjdk.java.net Fri May 7 15:28:50 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 15:28:50 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > Hi, Please review > > In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > Tests: tier1,tier2 > > Thanks > Yumin There also is concurrent issue at dynamic dump time (offline discussion with Ioi). We could encounter memory stomp when multiple threads adding to the global list, LambdaFormInvokers::_lambdaform_lines. That potentially screws some of the list entry up with inconsistent contents. The list should not grow once the dumping in progress. I will update with a lock to protect the list. ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From coleenp at openjdk.java.net Fri May 7 15:38:04 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 7 May 2021 15:38:04 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 125: > 123: // as any earlier causes security exceptions running the test and we > 124: // don't want to have to set up a policy file etc. > 125: System.setSecurityManager(new SecurityManager()); You might need to add the option -Djava.security.manager=allow to this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From akozlov at openjdk.java.net Fri May 7 15:45:29 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 7 May 2021 15:45:29 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint Message-ID: Hi, Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. I still owe a complete W^X approach description. Hope this patch does not depend much on that. ------------- Commit messages: - Check W^X at safepoint Changes: https://git.openjdk.java.net/jdk/pull/3920/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3920&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266742 Stats: 24 lines in 3 files changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3920.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3920/head:pull/3920 PR: https://git.openjdk.java.net/jdk/pull/3920 From coleenp at openjdk.java.net Fri May 7 16:04:58 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 7 May 2021 16:04:58 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v4] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 23:41:09 GMT, Claes Redestad wrote: >> This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. >> >> Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. >> >> This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Restructure initializer, reuse AdapterSignatureIterator in create_native_wrapper, minor improvements This looks good to me! src/hotspot/share/runtime/sharedRuntime.cpp line 2473: > 2471: case T_DOUBLE: st.print("D"); break; > 2472: case T_VOID: break; > 2473: default: ShouldNotReachHere(); For some reason, I thought there'd be some mapping from T_INT to JVM_SIGNATURE_INT that you could do st.print(signature_char(v)); and avoid this work. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3706 From gziemski at openjdk.java.net Fri May 7 16:20:26 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 7 May 2021 16:20:26 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure Message-ID: On x86_64 macOS the following sequence works just fine: attempt_reserve_memory_at(executable=false) commit_memory(executable=true) however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. Please note, that: attempt_reserve_memory_at(executable=true) commit_memory(executable=false) works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. ------------- Commit messages: - move the fix to modify the const int flags, leave the exec argument alone - pasted the workaround in wrong place, no need for __APPLE__ check - always use MAP_JIT when reserving memory on aarch64 macOS Changes: https://git.openjdk.java.net/jdk/pull/3865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262952 Stats: 8 lines in 2 files changed: 3 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3865/head:pull/3865 PR: https://git.openjdk.java.net/jdk/pull/3865 From pchilanomate at openjdk.java.net Fri May 7 18:30:52 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 7 May 2021 18:30:52 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition Message-ID: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Hi, Please review the following patch which contains the following cleanups: - Move _suspend_flags from Thread class to JavaThread - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. Tested in mach5 tiers 1-6. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/3919/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3919&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265934 Stats: 245 lines in 7 files changed: 107 ins; 116 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/3919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3919/head:pull/3919 PR: https://git.openjdk.java.net/jdk/pull/3919 From darcy at openjdk.java.net Fri May 7 20:34:29 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 7 May 2021 20:34:29 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: <9ObBYmFGUspGH8IrVNF58MhGkhAkXHF7lDFM60Q1uGI=.d68da03b-1604-4c95-ba4a-6d55f614af40@github.com> On Fri, 7 May 2021 10:34:49 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8266530 >> - Respond to review feedback. >> - 8266530: HotSpot changes for JEP 306 > > test/hotspot/jtreg/runtime/strictfp/AbstractStrictfpIntMethod60.jcod line 24: > >> 22: */ >> 23: >> 24: // Code below is equivalent to: > > If it is equivalent why do we need the jcod file? Presumably there is something here that differs from what the Java source would produce. An "abstract strictfp" method would be rejected at the source level by a Java compiler, hence the jcod files. Under the proposed language changes in JEP 306, the Java syntax around "strictfp" stays the same, including rejecting "abstract strictfp" method, but the floating-point semantics and defined to be (implicitly) always strict. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From iklam at openjdk.java.net Fri May 7 20:45:50 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 7 May 2021 20:45:50 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: <5e8ks2X0qGKFZ5QNGfRzO7-pWEtWPLiBCPLczTUi8_k=.27b57ace-c21b-4f7e-ac84-c9a9c099e4cd@github.com> On Fri, 7 May 2021 14:52:48 GMT, Yumin Qi wrote: > > > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > > > > > This is a disturbing statement given the breakage in the CI. Has sufficient testing > > been done to determine whether these other two bugs continue to happen or not. > > I'm really starting to wonder why the original fix wasn't backed out on Wednesday. > > > Hi Yumin, > > So there are three "exit" paths covered by this: > > > > * System.exit/halt > > * last thread terminates VM > > * -Xshare:dump > > > > so that seems reasonable. > > But I see a pre-existing problem that is now worse with this change. In JavaThread::invoke_shutdown_hooks we have this code: > > // We could get here with a pending exception, if so clear it now. > > if (this->has_pending_exception()) { > > this->clear_pending_exception(); > > } > > but that appears after the call to link_and_cleanup_shared_classes, so if in fact there is a pre-existing exception we will return from link_and_cleanup_shared_classes at the first CHECK (which is now on the newly moved code). > > In order to get the current crashes fixed we can address the exception issue in a follow up bug. > > Hi, David > Thanks for review. Yes, if the regeneration of holder classes returned with first CHECK, the exception is cleaned here. So the dump will be finished without finishing the original functions which link_and_cleanup_shared_classes intends to do. This requests LambdaFormInvokers::regnerate_holder_classes suppress all exceptions except for OOM (which exit directly from VM). This part needs an overall checking for various cases. Thanks for catching this. > > Yumin I created https://bugs.openjdk.java.net/browse/JDK-8266770 "Clean pending exception before running dynamic CDS dump" ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From darcy at openjdk.java.net Fri May 7 21:46:44 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 7 May 2021 21:46:44 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 10:44:59 GMT, David Holmes wrote: > > > Hi Joe, > > I don't really understand the proposed changes. If strictfp is implied to always be true that is fine, but if the ACC_STRICT modifier is applied then I don't see how it makes sense to allow it suddenly appear in places where it is not currently allowed. And if ACC_STRICT is to be undefined then I don't see how these changes suffice. ?? > > David Hi David, The proposed JVM spec change is that only strict evaluation is supported. Non-strict evaluation was (in practice) only possible on x86 and only if the old x87 FPU stack was being used. As of JDK-7175279: "Don't use x87 FPU on x86-64" fixed in JDK 15, at least 64-bit x86 code should be all-strict all the time in its implementation. No other supported CPU family could operate in a non-strict fashion. For the ACC_STRICT bit, the proposal is to keep with its current definition for major class file versions 46 through 60 but to undefine the bit for class file version 61 (JDK 17). If the bit is undefined for version 61, the rationale is it should be ignored for the "abstract && strictfp" check. -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From darcy at openjdk.java.net Fri May 7 21:47:17 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 7 May 2021 21:47:17 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v2] In-Reply-To: References: Message-ID: <1_-bE3EoBEhO1dgdJRjVwx2Vo6cbXxrZtHrjFvNc0PE=.9cf2f71b-4d63-4eff-88dc-94818e8a3d00@github.com> On Thu, 6 May 2021 19:58:00 GMT, Harold Seigel wrote: > > > Additional changes may be needed to these hotspot files that contain ACC_STRICT: > cpu/x86/templateTable_x86.cpp: __ testl(rcx, JVM_ACC_STRICT); > cpu/x86/templateTable_x86.cpp: __ testl(rcx, JVM_ACC_STRICT); > share/ci/ciFlags.hpp: bool is_strict () const { return (_flags & JVM_ACC_STRICT ) != 0; } > share/include/jvm_constants.h: JVM_ACC_STRICT | > share/utilities/accessFlags.hpp: bool is_strict () const { return (_flags & JVM_ACC_STRICT ) != 0; } > > Also, there are multiple hotspot tests that contain ACC_STRICT. As of JDK-7175279: "Don't use x87 FPU on x86-64", HotSpot shouldn't be able to have non-strict execution on any 64-bit platform. Non-strict execution is only possible using the x87 CPU instructions. For a 32-bit x86 port, either long strictfp-compliant mul/divide idioms need to be used or the SSE2 or later instructions. The nature of the spec shouldn't invalidate any existing tests, other than ones probing at "abstract && strictfp" for new class file versions. Thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From minqi at openjdk.java.net Fri May 7 21:58:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 21:58:27 GMT Subject: RFR: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > Hi, Please review > > In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > Tests: tier1,tier2 > > Thanks > Yumin Since the original fix is backed out, closed this PR without further progress, the redo of original bug will take care of this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From minqi at openjdk.java.net Fri May 7 21:58:28 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 21:58:28 GMT Subject: Withdrawn: 8266576: dynamicArchive/ParallelLambdaLoadTest.java crashes in tier2 testing In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:08:53 GMT, Yumin Qi wrote: > Hi, Please review > > In dynamic dump, the lambda invoker holder classes are regenerated in DynamicArchive::dump, which is after shutdown hook executed. The returned objects from the regeneration may contain invalid contents which caused crash like in this bug. It is late to execute java code, the fix is to move the call into MetaspaceShared::link_and_cleanup_shared_classes which is before shutdown hook, before halt. > JDK-8266585 and JDK-8266594 failed in different patterns, could be the same reason. > > Tests: tier1,tier2 > > Thanks > Yumin This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3910 From minqi at openjdk.java.net Fri May 7 22:08:04 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 22:08:04 GMT Subject: RFR: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Message-ID: Hi, Please review The integration of JDK-8255493 caused test case ParallelLambdaLoad failed which not found in mach5 pre-integration test. To fix the issue need more time, so decided to backout the original fix. Tests: local jtreg on runtime/cds/appcds tier1,tier2,tier3,tier4 (in progressing) Thanks Yumin ------------- Commit messages: - 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Changes: https://git.openjdk.java.net/jdk/pull/3928/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3928&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266765 Stats: 282 lines in 11 files changed: 23 ins; 224 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/3928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3928/head:pull/3928 PR: https://git.openjdk.java.net/jdk/pull/3928 From minqi at openjdk.java.net Fri May 7 22:35:36 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 22:35:36 GMT Subject: RFR: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: Message-ID: On Fri, 7 May 2021 20:48:16 GMT, Yumin Qi wrote: > Hi, Please review > > The integration of JDK-8255493 caused test case ParallelLambdaLoad failed which not found in mach5 pre-integration test. To fix the issue need more time, so decided to backout the original fix. > > Tests: local jtreg on runtime/cds/appcds > tier1,tier2,tier3,tier4 (in progressing) > > Thanks > Yumin The PR did not send out email, redo. ------------- PR: https://git.openjdk.java.net/jdk/pull/3928 From minqi at openjdk.java.net Fri May 7 22:35:36 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 22:35:36 GMT Subject: Withdrawn: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: Message-ID: On Fri, 7 May 2021 20:48:16 GMT, Yumin Qi wrote: > Hi, Please review > > The integration of JDK-8255493 caused test case ParallelLambdaLoad failed which not found in mach5 pre-integration test. To fix the issue need more time, so decided to backout the original fix. > > Tests: local jtreg on runtime/cds/appcds > tier1,tier2,tier3,tier4 (in progressing) > > Thanks > Yumin This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3928 From minqi at openjdk.java.net Fri May 7 23:22:32 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 23:22:32 GMT Subject: RFR: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Message-ID: Hi, Please review JDK-8255493 integration caused failures tier2/tier3 on test ParallelLambdaLoad.java which not caught in pre-integration tests. Since fix need more time, decided to back out the original fix. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Changes: https://git.openjdk.java.net/jdk/pull/3932/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3932&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266765 Stats: 285 lines in 11 files changed: 25 ins; 226 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3932.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3932/head:pull/3932 PR: https://git.openjdk.java.net/jdk/pull/3932 From dholmes at openjdk.java.net Fri May 7 23:23:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 7 May 2021 23:23:38 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 15:17:38 GMT, Coleen Phillimore wrote: >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > src/hotspot/share/oops/instanceKlass.cpp line 170: > >> 168: if (_nest_members == NULL || _nest_members == Universe::the_empty_short_array()) { >> 169: if (log_is_enabled(Trace, class, nestmates)) { >> 170: ResourceMark rm(current); > > Since THREAD is only used for ResourceMark and HandleMark which don't have to be a JavaThread, this parameter can just be Thread* current. And it should be in the first argument so it's not confused with CHECK. I can switch the argument order - that is a good suggestion and avoids the need for other changes. But I will still make it a JavaThread as only a JavaThread executes this code. > src/hotspot/share/oops/instanceKlass.cpp line 251: > >> 249: // are idempotent. >> 250: InstanceKlass* InstanceKlass::nest_host(TRAPS) { >> 251: JavaThread* current = THREAD->as_Java_thread(); > > I don't see why this is necessary to do this conversion. So that we don't use THREAD in the call to has_nest_member as it is not exception related. But if the Thread arg goes first on that call I can switch this back. > test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 69: > >> 67: } >> 68: >> 69: static byte[] getBytesForClass(String name) throws IOException { > > There's a ClassUnloadCommon library call for this. Thanks. I copied this from another test. If there's an existing utility I will switch to it. > test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 125: > >> 123: // as any earlier causes security exceptions running the test and we >> 124: // don't want to have to set up a policy file etc. >> 125: System.setSecurityManager(new SecurityManager()); > > You might need to add the option -Djava.security.manager=allow to this test. Thanks I'll check that out. ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From ccheung at openjdk.java.net Fri May 7 23:30:15 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 23:30:15 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes Message-ID: #ifdef ASSERT if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && !MetaspaceShared::remapped_readwrite() && !MetaspaceShared::is_old_class(m->method_holder())) { // At runtime initialize_itable is rerun as part of link_class_impl() // for a shared class loaded by the non-boot loader. // The dumptime itable method entry should be the same as the runtime entry. assert(_method == m, "sanity"); } #endif The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). While the method_holder() is not an old class, the _klass in the klassITable could be an old class. The proposed fix is to have the caller of the above function pass in the _klass and add another check making sure the _klass is not an old class before the assert. Testing: - [x] tiers 1 and 2 (including the new test) ------------- Commit messages: - 8266330: itableMethodEntry::initialize() asserts with archived old classes Changes: https://git.openjdk.java.net/jdk/pull/3930/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3930&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266330 Stats: 175 lines in 6 files changed: 169 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3930.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3930/head:pull/3930 PR: https://git.openjdk.java.net/jdk/pull/3930 From minqi at openjdk.java.net Fri May 7 23:53:35 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 7 May 2021 23:53:35 GMT Subject: RFR: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: Message-ID: On Fri, 7 May 2021 23:38:21 GMT, Calvin Cheung wrote: > Backout looks good. Thanks for quick review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3932 From ccheung at openjdk.java.net Fri May 7 23:53:34 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 7 May 2021 23:53:34 GMT Subject: RFR: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:52:19 GMT, Yumin Qi wrote: > Hi, Please review > JDK-8255493 integration caused failures tier2/tier3 on test ParallelLambdaLoad.java which not caught in pre-integration tests. Since fix need more time, decided to back out the original fix. > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Backout looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3932 From minqi at openjdk.java.net Sat May 8 00:06:17 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Sat, 8 May 2021 00:06:17 GMT Subject: Integrated: 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:52:19 GMT, Yumin Qi wrote: > Hi, Please review > JDK-8255493 integration caused failures tier2/tier3 on test ParallelLambdaLoad.java which not caught in pre-integration tests. Since fix need more time, decided to back out the original fix. > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: 04fad704 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/04fad70437a43c0f38fd53414b8eace2eac93509 Stats: 285 lines in 11 files changed: 25 ins; 226 del; 34 mod 8266765: [BACKOUT] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Reviewed-by: ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3932 From david.holmes at oracle.com Sat May 8 05:29:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 8 May 2021 15:29:03 +1000 Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On 8/05/2021 12:08 am, Harold Seigel wrote: > On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > LGTM. Thanks for fixing this. Thanks for the review Harold! David > Harold > > ------------- > > Marked as reviewed by hseigel (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3913 > From coleenp at openjdk.java.net Sat May 8 13:03:17 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 8 May 2021 13:03:17 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung wrote: > #ifdef ASSERT > if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > !MetaspaceShared::remapped_readwrite() && > !MetaspaceShared::is_old_class(m->method_holder())) { > // At runtime initialize_itable is rerun as part of link_class_impl() > // for a shared class loaded by the non-boot loader. > // The dumptime itable method entry should be the same as the runtime entry. > assert(_method == m, "sanity"); > } > #endif > > > The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). > While the method_holder() is not an old class, the _klass in the klassITable could be an old class. > The proposed fix is to have the caller of the above function pass in the _klass and add another check > making sure the _klass is not an old class before the assert. > > Testing: > - [x] tiers 1 and 2 (including the new test) Hi, the concept of 'old' class conflicts with the concept of 'old' methods which were ones that were redefined. I looked at this to see how redefinition could have broken this. One of these should change their name. In a future RFE, can you rename is_old_class to has_old_class_version(klass) ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3930 From iklam at openjdk.java.net Sun May 9 02:22:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 9 May 2021 02:22:54 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung wrote: > #ifdef ASSERT > if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > !MetaspaceShared::remapped_readwrite() && > !MetaspaceShared::is_old_class(m->method_holder())) { > // At runtime initialize_itable is rerun as part of link_class_impl() > // for a shared class loaded by the non-boot loader. > // The dumptime itable method entry should be the same as the runtime entry. > assert(_method == m, "sanity"); > } > #endif > > > The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). > While the method_holder() is not an old class, the _klass in the klassITable could be an old class. > The proposed fix is to have the caller of the above function pass in the _klass and add another check > making sure the _klass is not an old class before the assert. > > Testing: > - [x] tiers 1 and 2 (including the new test) LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3930 From minqi at openjdk.java.net Sun May 9 17:45:10 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Sun, 9 May 2021 17:45:10 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung wrote: > #ifdef ASSERT > if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > !MetaspaceShared::remapped_readwrite() && > !MetaspaceShared::is_old_class(m->method_holder())) { > // At runtime initialize_itable is rerun as part of link_class_impl() > // for a shared class loaded by the non-boot loader. > // The dumptime itable method entry should be the same as the runtime entry. > assert(_method == m, "sanity"); > } > #endif > > > The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). > While the method_holder() is not an old class, the _klass in the klassITable could be an old class. > The proposed fix is to have the caller of the above function pass in the _klass and add another check > making sure the _klass is not an old class before the assert. > > Testing: > - [x] tiers 1 and 2 (including the new test) LGTM, minor nits. src/hotspot/share/oops/klassVtable.cpp line 1097: > 1095: if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > 1096: !MetaspaceShared::remapped_readwrite() && > 1097: !MetaspaceShared::is_old_class(m->method_holder()) && !MetaspaceShared::is_old_class(klass)) { The newly added check should start with a new line as existing checks. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3930 From dholmes at openjdk.java.net Sun May 9 22:10:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 9 May 2021 22:10:24 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" [v2] In-Reply-To: References: Message-ID: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Update test per Coleen's comments: - need to add java.security.manager=allow just to be safe - simplify logic to read classfile from disk (ref ClassUnloadCommon.getClassData()) - Merge branch 'master' into 8261395-nestmember - Per Coleen: Reverse arguments order for has_nest_member so we can revert the introduction of "current". - Fix typo - Completely simpified the has_nest_member check to only use names. This avoids any possibility of class loading or executing any Java code and removes all possibility of exceptions in this part of the nestmate verification process. - Add test - Tweak logging message - 8261395: C1 crash "cannot make java calls from the native compiler" - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3913/files - new: https://git.openjdk.java.net/jdk/pull/3913/files/0025ac9d..353ac945 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3913&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3913&range=00-01 Stats: 9985 lines in 251 files changed: 6367 ins; 2386 del; 1232 mod Patch: https://git.openjdk.java.net/jdk/pull/3913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3913/head:pull/3913 PR: https://git.openjdk.java.net/jdk/pull/3913 From dholmes at openjdk.java.net Sun May 9 22:15:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 9 May 2021 22:15:17 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" [v2] In-Reply-To: References: Message-ID: <8yiH29yXjTxAmH1_oeAHF5_oAwIaHxNfx0tLEZ9sdNg=.94997495-e888-49fc-af22-14de1bf399bb@github.com> On Sun, 9 May 2021 22:10:24 GMT, David Holmes wrote: >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Update test per Coleen's comments: > - need to add java.security.manager=allow just to be safe > - simplify logic to read classfile from disk (ref ClassUnloadCommon.getClassData()) > - Merge branch 'master' into 8261395-nestmember > - Per Coleen: Reverse arguments order for has_nest_member so we can revert the introduction of "current". > - Fix typo > - Completely simpified the has_nest_member check to only use names. > This avoids any possibility of class loading or executing any Java > code and removes all possibility of exceptions in this part of the > nestmate verification process. > - Add test > - Tweak logging message > - 8261395: C1 crash "cannot make java calls from the native compiler" > - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. Thanks for the reviews Coleen, Ioi and Harold. Minor updates in place based on Coleen's feedback and suggestions. Please re-review. @coleenp we wouldn't have arrived at this simplified name-check-only version without all of the discussions and investigations of how to fix the more complex version. So credit remains where credit is due. :) Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From david.holmes at oracle.com Mon May 10 03:19:55 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 May 2021 13:19:55 +1000 Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: <6112097e-f8d6-a41b-af40-6131b8b70960@oracle.com> On 8/05/2021 11:03 pm, Coleen Phillimore wrote: > On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung wrote: > >> #ifdef ASSERT >> if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && >> !MetaspaceShared::remapped_readwrite() && >> !MetaspaceShared::is_old_class(m->method_holder())) { >> // At runtime initialize_itable is rerun as part of link_class_impl() >> // for a shared class loaded by the non-boot loader. >> // The dumptime itable method entry should be the same as the runtime entry. >> assert(_method == m, "sanity"); >> } >> #endif >> >> >> The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). >> While the method_holder() is not an old class, the _klass in the klassITable could be an old class. >> The proposed fix is to have the caller of the above function pass in the _klass and add another check >> making sure the _klass is not an old class before the assert. >> >> Testing: >> - [x] tiers 1 and 2 (including the new test) > > Hi, the concept of 'old' class conflicts with the concept of 'old' methods which were ones that were redefined. I looked at this to see how redefinition could have broken this. One of these should change their name. > In a future RFE, can you rename is_old_class to has_old_class_version(klass) ? Or even better define what "old" actually means in this API. It is defined as a classfile version < 50, but it isn't clear why that is significant to CDS. ?? Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3930 > From dholmes at openjdk.java.net Mon May 10 05:32:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 10 May 2021 05:32:42 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint In-Reply-To: References: Message-ID: <0fYZ1LpFwjF4ULZqdBaJVyPsifjVSyi55PpRbV3Kcp4=.30261f9b-4431-4efe-b6e7-fd595f44f3d8@github.com> On Fri, 7 May 2021 15:37:12 GMT, Anton Kozlov wrote: > Hi, > > Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). > > This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. > > I still owe a complete W^X approach description. Hope this patch does not depend much on that. Hi Anton, A few comments. Thanks, David src/hotspot/os/bsd/globals_bsd.hpp line 39: > 37: constraint) \ > 38: \ > 39: AARCH64_ONLY(develop(bool, WXCheckAtSafepoint, false, \ Why not enable always as this is a develop build? Do we even need to manage this on a flag? Also not really "safepoint" as the check also applies to handshakes. src/hotspot/share/runtime/thread.hpp line 688: > 686: WXMode enable_wx(WXMode new_state); > 687: > 688: void check_wx(WXMode expected) { assert_wx_state ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From dholmes at openjdk.java.net Mon May 10 05:47:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 10 May 2021 05:47:20 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > minor adjustment Hi, Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case? And what is the impact on other cases as we're now increasing the overhead of the hash computation. Thanks, David test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57: > 55: byte[] buf = new byte[100]; > 56: int size = writeClass(buf, "MH$$"); > 57: Class cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null); Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API? ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From redestad at openjdk.java.net Mon May 10 08:00:00 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 May 2021 08:00:00 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v5] In-Reply-To: References: Message-ID: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: assert id->iid ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3798/files - new: https://git.openjdk.java.net/jdk/pull/3798/files/04af49d6..d06002c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From redestad at openjdk.java.net Mon May 10 08:02:08 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 May 2021 08:02:08 GMT Subject: RFR: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters [v4] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 01:37:51 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Restructure initializer, reuse AdapterSignatureIterator in create_native_wrapper, minor improvements > > The latest version LGTM. Thanks for also testing out the alternative optimizations. @iklam @coleenp - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3706 From redestad at openjdk.java.net Mon May 10 08:05:05 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 May 2021 08:05:05 GMT Subject: Integrated: 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 00:27:56 GMT, Claes Redestad wrote: > This patch refactors AdapterHandlerLibrary initialization so that we can initialize a handful of commonly used adapters early during bootstrap, and avoid taking the AdapterHandlerLibrary_lock when looking up these adapters. > > Since the 5 most common adapters plus the abstract adapter constitutes roughly 60% of the method shapes loaded and linked on a Hello World, this means a relatively significant startup optimization (~2M insns on Hello World); most of the win is in lookup code that will be a significant part of the cost of class loading even when no adapters need to be generated. > > This enhancement partially recuperates the regression reported in https://bugs.openjdk.java.net/browse/JDK-8265523 This pull request has now been integrated. Changeset: 0f925d1f Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/0f925d1f58ffc0c56ae85a189798f8d99d90d443 Stats: 383 lines in 2 files changed: 229 ins; 65 del; 89 mod 8266015: Implement AdapterHandlerLibrary lookup fast-path for common adapters Reviewed-by: iklam, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3706 From redestad at openjdk.java.net Mon May 10 08:17:30 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 May 2021 08:17:30 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind [v6] In-Reply-To: References: Message-ID: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: 8259316 added call to is_empty_method in compilerOracle.cpp so we now need to include method.inline.hpp there ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3798/files - new: https://git.openjdk.java.net/jdk/pull/3798/files/d06002c9..9e11dc3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From aph at openjdk.java.net Mon May 10 09:46:07 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 10 May 2021 09:46:07 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: On Tue, 4 May 2021 19:34:18 GMT, Gerard Ziemski wrote: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. > > Please note, that: > > attempt_reserve_memory_at(executable=true) > commit_memory(executable=false) > > works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. > > Passes Mach5 hs-tier1,2,3,4,5 tests src/hotspot/os/bsd/os_bsd.cpp line 1708: > 1706: // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk > 1707: // later, so always reserve executable memory right from the start > 1708: MACOS_AARCH64_ONLY(| MAP_JIT); Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug? ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From redestad at openjdk.java.net Mon May 10 13:54:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 10 May 2021 13:54:40 GMT Subject: Integrated: 8266252: Streamline AbstractInterpreter::method_kind In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 16:04:54 GMT, Claes Redestad wrote: > This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. > > Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. > > Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. This pull request has now been integrated. Changeset: e41fd735 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/e41fd735296e6ad32c422d266a685f7b775be5c2 Stats: 98 lines in 4 files changed: 35 ins; 40 del; 23 mod 8266252: Streamline AbstractInterpreter::method_kind Reviewed-by: iklam, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3798 From hseigel at openjdk.java.net Mon May 10 14:02:23 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 10 May 2021 14:02:23 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Hi Joe, What regression tests were run against this change? Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From hseigel at openjdk.java.net Mon May 10 14:08:12 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 10 May 2021 14:08:12 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: <2qY6ENKff3wABfoT2sPTUyICosEXrOlQexRa_y8AgcE=.3cfef19d-8ed6-40f7-957b-a127dd209cc7@github.com> On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 So, for class file version 61, this function in method.hpp will return false because the flag is not set? bool is_strict() const { return access_flags().is_strict(); } If so, then won't that prevent strictfp semantics in share/c1/c1_GraphBuilder.cpp (and other places) that call is_strict(), such as: if (method()->is_strict()) { res = round_fp(res); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From gziemski at openjdk.java.net Mon May 10 15:55:58 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 10 May 2021 15:55:58 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: On Mon, 10 May 2021 09:43:56 GMT, Andrew Haley wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. >> >> Please note, that: >> >> attempt_reserve_memory_at(executable=true) >> commit_memory(executable=false) >> >> works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. >> >> Passes Mach5 hs-tier1,2,3,4,5 tests > > src/hotspot/os/bsd/os_bsd.cpp line 1708: > >> 1706: // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk >> 1707: // later, so always reserve executable memory right from the start >> 1708: MACOS_AARCH64_ONLY(| MAP_JIT); > > Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug? Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS. The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From calvin.cheung at oracle.com Mon May 10 16:12:29 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Mon, 10 May 2021 09:12:29 -0700 Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: <6112097e-f8d6-a41b-af40-6131b8b70960@oracle.com> References: <6112097e-f8d6-a41b-af40-6131b8b70960@oracle.com> Message-ID: <4d389a92-61fc-5bd3-34bb-97f074ce7e2b@oracle.com> On 5/9/21 8:19 PM, David Holmes wrote: > On 8/05/2021 11:03 pm, Coleen Phillimore wrote: >> On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung >> wrote: >> >>> #ifdef ASSERT >>> ?? if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && >>> ????? !MetaspaceShared::remapped_readwrite() && >>> ????? !MetaspaceShared::is_old_class(m->method_holder())) { >>> ???? // At runtime initialize_itable is rerun as part of >>> link_class_impl() >>> ???? // for a shared class loaded by the non-boot loader. >>> ???? // The dumptime itable method entry should be the same as the >>> runtime entry. >>> ???? assert(_method == m, "sanity"); >>> ?? } >>> #endif >>> >>> >>> The above includes the check for >>> !MetaspaceShared::is_old_class(m->method_holder()). >>> While the method_holder() is not an old class, the _klass in the >>> klassITable could be an old class. >>> The proposed fix is to have the caller of the above function pass in >>> the _klass and add another check >>> making sure the _klass is not an old class before the assert. >>> >>> Testing: >>> - [x] tiers 1 and 2 (including the new test) >> >> Hi, the concept of 'old' class conflicts with the concept of 'old' >> methods which were ones that were redefined.? I looked at this to see >> how redefinition could have broken this. One of these should change >> their name. >> In a future RFE, can you rename is_old_class to >> has_old_class_version(klass) ? > > Or even better define what "old" actually means in this API. It is > defined as a classfile version < 50, but it isn't clear why that is > significant to CDS. ?? I've filed https://bugs.openjdk.java.net/browse/JDK-8266822 for the above. thanks, Calvin > > Thanks, > David > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/3930 >> From ccheung at openjdk.java.net Mon May 10 16:12:54 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 10 May 2021 16:12:54 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Sat, 8 May 2021 13:00:22 GMT, Coleen Phillimore wrote: > Hi, the concept of 'old' class conflicts with the concept of 'old' methods which were ones that were redefined. I looked at this to see how redefinition could have broken this. One of these should change their name. > In a future RFE, can you rename is_old_class to has_old_class_version(klass) ? @coleenp Thanks for your review. I've filed https://bugs.openjdk.java.net/browse/JDK-8266822 for your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3930 From ccheung at openjdk.java.net Mon May 10 16:12:54 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 10 May 2021 16:12:54 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Sun, 9 May 2021 17:42:13 GMT, Yumin Qi wrote: > LGTM @iklam Thanks! > LGTM, minor nits. @yminqi Thanks for your review. I've fixed the nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3930 From ccheung at openjdk.java.net Mon May 10 16:29:13 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 10 May 2021 16:29:13 GMT Subject: RFR: 8266330: itableMethodEntry::initialize() asserts with archived old classes [v2] In-Reply-To: References: Message-ID: > #ifdef ASSERT > if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > !MetaspaceShared::remapped_readwrite() && > !MetaspaceShared::is_old_class(m->method_holder())) { > // At runtime initialize_itable is rerun as part of link_class_impl() > // for a shared class loaded by the non-boot loader. > // The dumptime itable method entry should be the same as the runtime entry. > assert(_method == m, "sanity"); > } > #endif > > > The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). > While the method_holder() is not an old class, the _klass in the klassITable could be an old class. > The proposed fix is to have the caller of the above function pass in the _klass and add another check > making sure the _klass is not an old class before the assert. > > Testing: > - [x] tiers 1 and 2 (including the new test) Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: fix minor nit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3930/files - new: https://git.openjdk.java.net/jdk/pull/3930/files/6b83ea9f..6d31bae8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3930&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3930&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3930.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3930/head:pull/3930 PR: https://git.openjdk.java.net/jdk/pull/3930 From ccheung at openjdk.java.net Mon May 10 16:29:14 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 10 May 2021 16:29:14 GMT Subject: Integrated: 8266330: itableMethodEntry::initialize() asserts with archived old classes In-Reply-To: References: Message-ID: On Fri, 7 May 2021 22:32:33 GMT, Calvin Cheung wrote: > #ifdef ASSERT > if (MetaspaceShared::is_in_shared_metaspace((void*)&_method) && > !MetaspaceShared::remapped_readwrite() && > !MetaspaceShared::is_old_class(m->method_holder())) { > // At runtime initialize_itable is rerun as part of link_class_impl() > // for a shared class loaded by the non-boot loader. > // The dumptime itable method entry should be the same as the runtime entry. > assert(_method == m, "sanity"); > } > #endif > > > The above includes the check for !MetaspaceShared::is_old_class(m->method_holder()). > While the method_holder() is not an old class, the _klass in the klassITable could be an old class. > The proposed fix is to have the caller of the above function pass in the _klass and add another check > making sure the _klass is not an old class before the assert. > > Testing: > - [x] tiers 1 and 2 (including the new test) This pull request has now been integrated. Changeset: 25d99e52 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/25d99e52679bdf4601058e10e5679ca3780f8ec3 Stats: 176 lines in 6 files changed: 170 ins; 0 del; 6 mod 8266330: itableMethodEntry::initialize() asserts with archived old classes Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/3930 From darcy at openjdk.java.net Mon May 10 16:52:56 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 10 May 2021 16:52:56 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 13:58:34 GMT, Harold Seigel wrote: > > > Hi Joe, > What regression tests were run against this change? > Thanks, Harold Hi Harold, Tier 1 through 3 regression tests across platforms. Thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From darcy at openjdk.java.net Mon May 10 17:21:59 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 10 May 2021 17:21:59 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: <2qY6ENKff3wABfoT2sPTUyICosEXrOlQexRa_y8AgcE=.3cfef19d-8ed6-40f7-957b-a127dd209cc7@github.com> References: <2qY6ENKff3wABfoT2sPTUyICosEXrOlQexRa_y8AgcE=.3cfef19d-8ed6-40f7-957b-a127dd209cc7@github.com> Message-ID: <3xbmW7WeqYCaOfUSA7b7BfHm65kFweV_mX0fE01125Y=.f8292524-3e20-431c-8520-3652c9d276c2@github.com> On Mon, 10 May 2021 14:05:27 GMT, Harold Seigel wrote: > > > So, for class file version 61, this function in method.hpp will return false because the flag is not set? > > ``` > bool is_strict() const { return access_flags().is_strict(); } > ``` > > If so, then won't that prevent strictfp semantics in share/c1/c1_GraphBuilder.cpp (and other places) that call is_strict(), such as: > > if (method()->is_strict()) { > res = round_fp(res); > } Nearly all floating-point computation on Hotspot has been strict-in-practice even if it isn't marked as being mandated as strictfp. From what I can tell, the code in c1_GraphBuilder looks to be vestiges of x87 support. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From ddong at openjdk.java.net Mon May 10 17:43:55 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 10 May 2021 17:43:55 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > minor adjustment Hi David, Thanks for your comment! > Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case? Actually, the performance problem we noticed occurred in jdk 11u, here's a simplified piece of code: import java.lang.invoke.*; import java.util.*; class Test { public static void main(String[] args) throws Throwable{ MethodType mt = MethodType.methodType(void.class); List mhs = new ArrayList<>(); for (int i = 0; i < 2000; i++) { // In practice, it will point to different methods mhs.add(MethodHandles.lookup().findVirtual(Test.class, "call", MethodType.methodType(void.class)) .bindTo(new Test())); } for (int i = 0; i < 128; i++) { for (MethodHandle mh : mhs) { mh.invokeExact(); } } } void call() {} } Run: `java -Xlog:membername+table=debug Test`, and we can see that all of the LambdaForm$MH use a same slot. [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254840.invoke(Ljava/lang/Object;)V index 219 [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254c40.invoke(Ljava/lang/Object;)V index 219 [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255040.invoke(Ljava/lang/Object;)V index 219 [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255440.invoke(Ljava/lang/Object;)V index 219 This problem doesn't exist in jdk upstream because of the name-mangling mechanism for hidden class(ClassFileParser::mangle_hidden_class_name). However, if the user creates many classes with the same name by different classloaders, the performance problems will still appear, although I also think that the general user will not implement the code in this way. My plan is to fix this problem in the upstream and then backport it to JDK 11, what do you think? > And what is the impact on other cases as we're now increasing the overhead of the hash computation. I think the overhead is negligible, here is a benchmark based on ResolvedMethodTableHash.java: import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Warmup; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.nio.ByteBuffer; import java.util.ArrayList; import java.util.List; import java.util.Random; @State(Scope.Benchmark) public class MyBenchmark extends ClassLoader { // Produce a class file with the given name and a single method: // public static native void m(); private int writeClass(byte[] buf, String className) { ... same as ResolvedMethodTableHash.java } private List> classes = new ArrayList<>(); private Random r = new Random(); @Setup public void prepare() throws Exception { for (int i = 0; i < 5000; i ++) { byte[] buf = new byte[100]; int size = writeClass(buf, "MH$" + i); classes.add(defineClass(null, buf, 0, size)); } } @Benchmark @Fork(value=1) @Warmup(iterations = 5, time = 1) public void test(Blackhole bh) throws Exception { MethodHandle mh = MethodHandles.publicLookup().findStatic(classes.get(r.nextInt(5000)), "m", MethodType.methodType(void.class)); if (mh == null) { throw new RuntimeException(); } } } on linux x86_64, result with the patch: Result: 904126.215 ?(99.9%) 26603.356 ops/s [Average] Statistics: (min, avg, max) = (852079.715, 904126.215, 927791.630), stdev = 30636.464 Confidence interval (99.9%): [877522.859, 930729.571] Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.test thrpt 20 904126.215 26603.356 ops/s result without the patch: Result: 883669.014 ?(99.9%) 26455.778 ops/s [Average] Statistics: (min, avg, max) = (830830.551, 883669.014, 906978.220), stdev = 30466.514 Confidence interval (99.9%): [857213.236, 910124.792] Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.test thrpt 20 883669.014 26455.778 ops/s ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Mon May 10 17:43:56 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 10 May 2021 17:43:56 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 05:40:50 GMT, David Holmes wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> minor adjustment > > test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57: > >> 55: byte[] buf = new byte[100]; >> 56: int size = writeClass(buf, "MH$$"); >> 57: Class cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null); > > Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API? Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From hseigel at openjdk.java.net Mon May 10 19:14:18 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 10 May 2021 19:14:18 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Hi Joe, If the code that calls is_strict() (and other code that looks at ACC_STRICT) is no longer needed then it should be removed. Otherwise, that code should be changed to also check if ik->major_version() >= 61. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From hseigel at openjdk.java.net Mon May 10 20:22:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 10 May 2021 20:22:54 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) This is a nice cleanup. The copyrights need updating. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3879 From ccheung at openjdk.java.net Mon May 10 20:33:55 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 10 May 2021 20:33:55 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Mon, 10 May 2021 17:48:51 GMT, Yumin Qi wrote: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin The incremental changes look good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3953 From mseledtsov at openjdk.java.net Mon May 10 20:37:53 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 10 May 2021 20:37:53 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) Change looks good to me. Thanks for doing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3879 From john.r.rose at oracle.com Mon May 10 20:42:35 2021 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 May 2021 20:42:35 +0000 Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> Message-ID: On May 5, 2021, at 2:27 PM, Remi Forax > wrote: If possible, I would prefer ACC_STRICT to be banned instead of being ignored, for version >= 51. I sympathize with this, and I had hoped (when Joe set out on this work) that the JVMS would cooperate. But it doesn?t, in the most straightforward interpretation. (And yes, we are making new interpretations here because we are on new ground. And it is natural to get here after a quarter century; the question is where to aim for the next quarter century.) On May 7, 2021, at 3:47 AM, David Holmes > wrote: I'm not sure it makes sense to allow ACC_STRICT to suddenly appear where it would otherwise be illegal. ?? This does seem surprising, but it is a clean consequence of the stated goal of removing the access modifier from the JVM specification. As soon as 0x0800 (ACC_STRICT) becomes an undefined flag, non-zero settings become legal in all cases. However paradoxical, this follows from the JVMS language which Joe quotes. I?d like to change that behavior eventually, but that would be a separate step. On May 5, 2021, at 2:51 PM, Joe Darcy > wrote: "All bits of the access_flags item not assigned in Table 4.6-A are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations. The JVMS discourages but does not disallows the setting of undefined class file bits. The simplest removal of ACC_STRICT will revert it to the status of an undefined bit, which can be set to nonzero but? ?should be set to zero?. Or else?? There is no ?or else? specified, therefore we can?t spring a new error on the user. I think we may need a JEP to define stricter rules for undefined modifiers. (And maybe more JEP work for other undefined classfile states, though a quick search doesn?t reveal any good candidates.) The JEP?s mandated checking can have well-defined interactions with configuration flags, such as preview or experimental modes, or even a permanent ?strict? vs. ?lax? JVM flag. Then we can more confidently extend those undefined or ignored `access_flag` bits, to well-defined bits. At that point we can recycle the bit position occupied by 0x0800 (ACC_STRICT), since we will then be confident there will be no undiagnosed noise in that unused channel. It might seem reasonable to, at least, anticipate such an improvement to the spec, in the one case of ACC_STRICT, and require JVMs to throw an error on the vacated bit. Indeed, this would be another ?interpretation? of the intent of theJVM spec, in this new case of removing the definition of a modifier bit. But it would add spec complexity to the JVM (after strictfp removal) for little gain: The special treatment of the vacated bit would, indeed, allow it to be recycled sooner, and lagging tools would be diagnosed more easily. But that?s not enough benefit, IMO, to remove strictfp and *then* make its vacated bit position into sacred ground that is different from that in other bit positions. (A counter argument is that, since we have insisted that class file generation tools, to date, be able to emit ACC_STRICT in certain circumstances, we should help them back away from that behavior by having the JVM reject such outputs. But this can be handled by a different tool or tool mode, better than having the JVM spec centralize such checks.) So I think on balance it?s best to adjust the JVM spec now to appear as if ACC_STRICT had never happened (relative to up-rev class files), and consider solving the wider problem of undefined modifiers, as a separate line of work. ? John From lfoltan at openjdk.java.net Mon May 10 20:50:09 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 10 May 2021 20:50:09 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) Cleanup looks good Vladimir! Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3879 From minqi at openjdk.java.net Mon May 10 20:51:08 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 10 May 2021 20:51:08 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Mon, 10 May 2021 20:31:05 GMT, Calvin Cheung wrote: >> Hi, please review >> This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. >> The old PR description: >> ------------- old ------------ >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> ------------ new ------------- >> The new fix (incremental) >> 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. >> 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. >> 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. >> 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. >> >> Tests: tier1,tier2,tier3,tier4 >> local test on runtime/cds >> local test ParallelLambdaLoadTest.java in loops without crash. >> >> Thanks >> Yumin > > The incremental changes look good. @calvinccheung Thanks for review again! ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From forax at univ-mlv.fr Mon May 10 21:50:29 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 10 May 2021 23:50:29 +0200 (CEST) Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> Message-ID: <782375682.893863.1620683429148.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" , "David Holmes" > Cc: "hotspot-runtime-dev" > Envoy?: Lundi 10 Mai 2021 22:42:35 > Objet: Re: RFR: 8266530: HotSpot changes for JEP 306 > On May 5, 2021, at 2:27 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> If possible, I would prefer ACC_STRICT to be banned instead of being ignored, >> for version >= 51. > I sympathize with this, and I had hoped (when Joe set out > on this work) that the JVMS would cooperate. But it doesn?t, > in the most straightforward interpretation. (And yes, we > are making new interpretations here because we are on > new ground. And it is natural to get here after a quarter > century; the question is where to aim for the next quarter > century.) > On May 7, 2021, at 3:47 AM, David Holmes < [ mailto:dholmes at openjdk.java.net | > dholmes at openjdk.java.net ] > wrote: >> I'm not sure it makes sense to allow ACC_STRICT to suddenly appear where it >> would otherwise be illegal. ?? > This does seem surprising, but it is a clean consequence > of the stated goal of removing the access modifier from > the JVM specification. As soon as 0x0800 (ACC_STRICT) > becomes an undefined flag, non-zero settings become > legal in all cases. However paradoxical, this follows > from the JVMS language which Joe quotes. I?d like > to change that behavior eventually, but that would be > a separate step. > On May 5, 2021, at 2:51 PM, Joe Darcy < [ mailto:joe.darcy at oracle.com | > joe.darcy at oracle.com ] > wrote: >> "All bits of the access_flags item not assigned in Table 4.6-A are reserved for >> future use. They should be set to zero in generated class files and should be >> ignored by Java Virtual Machine implementations. > The JVMS discourages but does not disallows the setting of > undefined class file bits. The simplest removal of ACC_STRICT > will revert it to the status of an undefined bit, which can be > set to nonzero but? ?should be set to zero?. Or else?? There > is no ?or else? specified, therefore we can?t spring a new error > on the user. > I think we may need a JEP to define stricter rules for undefined > modifiers. (And maybe more JEP work for other undefined > classfile states, though a quick search doesn?t reveal any good > candidates.) The JEP?s mandated checking can have well-defined > interactions with configuration flags, such as preview or > experimental modes, or even a permanent ?strict? vs. ?lax? > JVM flag. > Then we can more confidently extend those undefined or > ignored `access_flag` bits, to well-defined bits. At that > point we can recycle the bit position occupied by > 0x0800 (ACC_STRICT), since we will then be confident > there will be no undiagnosed noise in that unused channel. > It might seem reasonable to, at least, anticipate such an > improvement to the spec, in the one case of ACC_STRICT, > and require JVMs to throw an error on the vacated bit. > Indeed, this would be another ?interpretation? of the > intent of theJVM spec, in this new case of removing the > definition of a modifier bit. But it would add spec > complexity to the JVM (after strictfp removal) for > little gain: The special treatment of the vacated bit > would, indeed, allow it to be recycled sooner, and > lagging tools would be diagnosed more easily. But > that?s not enough benefit, IMO, to remove strictfp > and *then* make its vacated bit position into sacred > ground that is different from that in other bit positions. > (A counter argument is that, since we have insisted > that class file generation tools, to date, be able to emit > ACC_STRICT in certain circumstances, we should > help them back away from that behavior by having the > JVM reject such outputs. But this can be handled by > a different tool or tool mode, better than having the > JVM spec centralize such checks.) All the tools that o know that checks the bytecode are using the JVMS to define their semantics, so if the JVMS is not strict about ACC_STRICT, no existing tools will be, a special tool can be created but will it be used, just for detecting ACC_STRICT, i don't think so. So i may be wrong but if the JVMS semantics uses a lax approach about ACC_STRICT, it will have to be stricter at some point in order to reuse 0x800, so in a sense the current position is "we will see later when we will need it", which is not a bad position, because perhaps 0x800 will never be reused, or reused but only composed with another bit like ACC_ABSTRACT | ACC_STRICT. > So I think on balance it?s best to adjust the JVM spec > now to appear as if ACC_STRICT had never happened > (relative to up-rev class files), and consider solving the > wider problem of undefined modifiers, as a separate line > of work. > ? John R?mi From cjplummer at openjdk.java.net Mon May 10 23:33:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:33:08 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 08:45:45 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > code refine and typo fix I think you still need to undo the JMap.java changes since they are now being handled by #3598 ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From cjplummer at openjdk.java.net Mon May 10 23:46:24 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:46:24 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. Marked as reviewed by cjplummer (Reviewer). Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From dholmes at openjdk.java.net Tue May 11 00:12:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 00:12:55 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) Hi Vladimir, Great to see this cleanup happen. I couldn't verify every change naturally but in general it looks good. The proof of course is in the running of the tests. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3879 From david.holmes at oracle.com Tue May 11 00:20:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 10:20:29 +1000 Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: Message-ID: <460f262d-4798-4df2-4eb2-130eec72ec29@oracle.com> On 11/05/2021 5:14 am, Harold Seigel wrote: > On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: > >>> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >>> >>> JEP 306 is considering the following changes to the JVMS: >>> >>> 1) Require "strict" floating-point evaluation in all circumstances. >>> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >>> >>> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >>> >>> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >>> >>> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >>> >>> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >>> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >>> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. >> >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8266530 >> - Respond to review feedback. >> - 8266530: HotSpot changes for JEP 306 > > Hi Joe, > If the code that calls is_strict() (and other code that looks at ACC_STRICT) is no longer needed then it should be removed. Otherwise, that code should be changed to also check if ik->major_version() >= 61. Right - the normal process would be to update the code based on is_strict() always returning true thus eliding it, but retaining the code it causes to be called. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3891 > From dholmes at openjdk.java.net Tue May 11 00:31:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 00:31:35 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 17:40:51 GMT, Denghui Dong wrote: >> test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57: >> >>> 55: byte[] buf = new byte[100]; >>> 56: int size = writeClass(buf, "MH$$"); >>> 57: Class cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null); >> >> Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API? > > Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose. But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From david.holmes at oracle.com Tue May 11 00:45:00 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 10:45:00 +1000 Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: <1a6eeb30-1d67-b604-740d-682de612642c@oracle.com> On 11/05/2021 3:43 am, Denghui Dong wrote: > On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong wrote: > >>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. >> >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> minor adjustment > > Hi David, > > Thanks for your comment! > >> Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case? > > Actually, the performance problem we noticed occurred in jdk 11u, here's a simplified piece of code: Is there a real benchmark that demonstrates this, rather than a micro-benchmark? I'm just trying to understand under conditions this is a real problem. > > import java.lang.invoke.*; > import java.util.*; > > class Test { > public static void main(String[] args) throws Throwable{ > MethodType mt = MethodType.methodType(void.class); > > List mhs = new ArrayList<>(); > for (int i = 0; i < 2000; i++) { > // In practice, it will point to different methods > mhs.add(MethodHandles.lookup().findVirtual(Test.class, "call", > MethodType.methodType(void.class)) > .bindTo(new Test())); > } > > for (int i = 0; i < 128; i++) { > for (MethodHandle mh : mhs) { > mh.invokeExact(); > } > } > } > > void call() {} > } > > > Run: `java -Xlog:membername+table=debug Test`, and we can see that all of the LambdaForm$MH use a same slot. > > [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254840.invoke(Ljava/lang/Object;)V index 219 > [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800254c40.invoke(Ljava/lang/Object;)V index 219 > [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255040.invoke(Ljava/lang/Object;)V index 219 > [0.359s][debug][membername,table] ResolvedMethod entry added for java.lang.invoke.LambdaForm$MH/0x0000000800255440.invoke(Ljava/lang/Object;)V index 219 > > > > This problem doesn't exist in jdk upstream because of the name-mangling mechanism for hidden class(ClassFileParser::mangle_hidden_class_name). Is the output above from JDK 17 or JDK 11? It seems to show the mangled (well "adorned") name, so shouldn't they map to different hash buckets anyway? > However, if the user creates many classes with the same name by different classloaders, the performance problems will still appear, although I also think that the general user will not implement the code in this way. > > My plan is to fix this problem in the upstream and then backport it to JDK 11, what do you think? I'm not sure it is the right approach to "fix" a problem that doesn't really exist in mainline just so it can be backported to 11u >> And what is the impact on other cases as we're now increasing the overhead of the hash computation. > > I think the overhead is negligible, here is a benchmark based on ResolvedMethodTableHash.java: Thanks for confirming. David > > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Fork; > import org.openjdk.jmh.annotations.Warmup; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.infra.Blackhole; > > import java.lang.invoke.MethodHandle; > import java.lang.invoke.MethodHandles; > import java.lang.invoke.MethodType; > import java.nio.ByteBuffer; > import java.util.ArrayList; > import java.util.List; > import java.util.Random; > > @State(Scope.Benchmark) > public class MyBenchmark extends ClassLoader { > > // Produce a class file with the given name and a single method: > // public static native void m(); > private int writeClass(byte[] buf, String className) { > ... same as ResolvedMethodTableHash.java > } > > private List> classes = new ArrayList<>(); > private Random r = new Random(); > > @Setup > public void prepare() throws Exception { > for (int i = 0; i < 5000; i ++) { > byte[] buf = new byte[100]; > int size = writeClass(buf, "MH$" + i); > classes.add(defineClass(null, buf, 0, size)); > } > } > > > @Benchmark > @Fork(value=1) > @Warmup(iterations = 5, time = 1) > public void test(Blackhole bh) throws Exception { > MethodHandle mh = MethodHandles.publicLookup().findStatic(classes.get(r.nextInt(5000)), > "m", MethodType.methodType(void.class)); > if (mh == null) { > throw new RuntimeException(); > } > } > } > > > on linux x86_64, > > result with the patch: > > Result: 904126.215 ?(99.9%) 26603.356 ops/s [Average] > Statistics: (min, avg, max) = (852079.715, 904126.215, 927791.630), stdev = 30636.464 > Confidence interval (99.9%): [877522.859, 930729.571] > > Benchmark Mode Samples Score Score error Units > o.s.MyBenchmark.test thrpt 20 904126.215 26603.356 ops/s > > > result without the patch: > > Result: 883669.014 ?(99.9%) 26455.778 ops/s [Average] > Statistics: (min, avg, max) = (830830.551, 883669.014, 906978.220), stdev = 30466.514 > Confidence interval (99.9%): [857213.236, 910124.792] > > Benchmark Mode Samples Score Score error Units > o.s.MyBenchmark.test thrpt 20 883669.014 26455.778 ops/s > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3901 > From dholmes at openjdk.java.net Tue May 11 01:07:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 01:07:01 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Mon, 10 May 2021 17:48:51 GMT, Yumin Qi wrote: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Hi Yumin, Not a review but I noticed that in dynamicArchive.cpp at lines 173 and 254 we introduce unused THREAD variables. Could you delete them please. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From mli at openjdk.java.net Tue May 11 01:24:02 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 11 May 2021 01:24:02 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler Message-ID: This is trivial change to remove dead code in low memory detector. ------------- Commit messages: - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler - JDK-8266795: remove dead code LowMemoryDetectorDisabler Changes: https://git.openjdk.java.net/jdk/pull/3964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3964&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266795 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3964/head:pull/3964 PR: https://git.openjdk.java.net/jdk/pull/3964 From dholmes at openjdk.java.net Tue May 11 02:33:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 02:33:54 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler In-Reply-To: References: Message-ID: <6iY4w1YyGyWrox27FEbHeUQZa3VXp3hOFSqtIsY0WDo=.01ddb98c-c415-4b1f-ae6e-a62f9fd1e233@github.com> On Tue, 11 May 2021 01:16:27 GMT, Hamlin Li wrote: > This is trivial change to remove dead code in low memory detector. Hi Hamlin, What you have seems fine, but unless I missed something it seems the whole notion of being enabled/disabled is unused: // > 0 if temporary disabed static volatile jint _disabled_count; static bool temporary_disabled() { return _disabled_count > 0; } static void disable() { Atomic::inc(&_disabled_count); } static void enable() { Atomic::dec(&_disabled_count); } Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3964 From ddong at openjdk.java.net Tue May 11 02:37:51 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 11 May 2021 02:37:51 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> On Tue, 11 May 2021 00:27:47 GMT, David Holmes wrote: >> Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose. > > But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ?? Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream: // - for unsafe anonymous class: create a new CLD whith a class holder that uses // the same class loader as the unsafe_anonymous_host. // - for hidden classes that are not strong: create a new CLD that has a class holder and // whose loader is the Lookup class's loader. // - for hidden class: add the class to the Lookup class's loader's CLD. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From david.holmes at oracle.com Tue May 11 02:52:19 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 12:52:19 +1000 Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> References: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> Message-ID: On 11/05/2021 12:37 pm, Denghui Dong wrote: > On Tue, 11 May 2021 00:27:47 GMT, David Holmes wrote: > >>> Because here needs different class loader data to load the different classes with the same name, I think Unsafe API is a simple way to achieve this purpose. >> >> But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ?? > > Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream: > > // - for unsafe anonymous class: create a new CLD whith a class holder that uses > // the same class loader as the unsafe_anonymous_host. > // - for hidden classes that are not strong: create a new CLD that has a class holder and > // whose loader is the Lookup class's loader. > // - for hidden class: add the class to the Lookup class's loader's CLD. Okay but we should only be concerned about the behaviour of public API's, so we should be testing and benchmarking those API's. defineAnonymousClass() maybe relevant for 11u, but not mainline. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3901 > From ddong at openjdk.java.net Tue May 11 02:52:24 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 11 May 2021 02:52:24 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 06:27:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > minor adjustment > Is there a real benchmark that demonstrates this, rather than a > micro-benchmark? I'm just trying to understand under conditions this is > a real problem. Sorry, I don't have a real benchmark yet. I think the code snippets I provided before will exist in many current applications that rely on method handles. > Is the output above from JDK 17 or JDK 11? It seems to show the mangled > (well "adorned") name, so shouldn't they map to different hash buckets > anyway? >From JDK 11. The reason why the name displayed in the log is different is because the external name of the target klass is used (see Method::name_and_sig_as_C_string), and in 11, all java.lang.invoke.LambdaForm$MH have the same name( that's why the slot index are the same). > I'm not sure it is the right approach to "fix" a problem that doesn't > really exist in mainline just so it can be backported to 11u >From my perspective, I think that this problem still exists in the mainline, but users will hardly write code that causes this problem. Since this patch will not cause obvious performance problems, I think it is harmless to add it to the main-line. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From minqi at openjdk.java.net Tue May 11 03:11:55 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 03:11:55 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Tue, 11 May 2021 01:04:02 GMT, David Holmes wrote: > Hi Yumin, > > Not a review but I noticed that in dynamicArchive.cpp at lines 173 and 254 we introduce unused THREAD variables. Could you delete them please. > > Thanks, > David Sure, thanks for catching that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From ddong at openjdk.java.net Tue May 11 03:12:55 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 11 May 2021 03:12:55 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> References: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> Message-ID: <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com> On Tue, 11 May 2021 02:35:13 GMT, Denghui Dong wrote: >> But as you note, the name mangling for hidden classes would mean that the names are not actually the same. And I don't see how this introduces a different classloader-data. ?? > > Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream: > > // - for unsafe anonymous class: create a new CLD whith a class holder that uses > // the same class loader as the unsafe_anonymous_host. > // - for hidden classes that are not strong: create a new CLD that has a class holder and > // whose loader is the Lookup class's loader. > // - for hidden class: add the class to the Lookup class's loader's CLD. > Okay but we should only be concerned about the behaviour of public > API's, so we should be testing and benchmarking those API's. > defineAnonymousClass() maybe relevant for 11u, but not mainline. I can use public API. Another reason I used Unsafe API here is for saving metaspace. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From lzang at openjdk.java.net Tue May 11 03:19:05 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 03:19:05 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - remove parallel option and dumpheapext command - Revert "hide the dumpheapext error message" This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=22 Stats: 840 lines in 5 files changed: 653 ins; 61 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From ddong at openjdk.java.net Tue May 11 03:19:24 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 11 May 2021 03:19:24 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v3] In-Reply-To: References: Message-ID: <8UENWXduGb1mHVlUEED98dvk8wCMFd1jlIYxkVT0mBk=.17d48971-8ff6-4a58-a687-7584a65f82de@github.com> > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with two additional commits since the last revision: - remove useless lines - use public api ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/8d500a84..82d8cc6c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Tue May 11 03:19:24 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 11 May 2021 03:19:24 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v2] In-Reply-To: <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com> References: <-LOqsRJbfv_P1ZJENBFMfKA-0FM1bBtwOhK5BUVIZeU=.9eac2992-af32-4af8-83e6-88abfbfb8a34@github.com> <1luDs45T6ia9T_kzfLNCod2E36WrhmNZsGE8qnPxIqk=.da32b1d2-5b4f-4eba-af59-a559755f2651@github.com> Message-ID: On Tue, 11 May 2021 03:10:20 GMT, Denghui Dong wrote: >> Unsafe.getUnsafe().defineAnonymousClass will create an unsafe anonymous class rather than a hidden class, and for unsafe anonymous class, JVM will create a new CLD, see the comment in SystemDictionary::resolve_hidden_class_from_stream: >> >> // - for unsafe anonymous class: create a new CLD whith a class holder that uses >> // the same class loader as the unsafe_anonymous_host. >> // - for hidden classes that are not strong: create a new CLD that has a class holder and >> // whose loader is the Lookup class's loader. >> // - for hidden class: add the class to the Lookup class's loader's CLD. > >> Okay but we should only be concerned about the behaviour of public >> API's, so we should be testing and benchmarking those API's. > >> defineAnonymousClass() maybe relevant for 11u, but not mainline. > > I can use public API. > Another reason I used Unsafe API here is for saving metaspace. updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From minqi at openjdk.java.net Tue May 11 03:24:23 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 03:24:23 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove unused variables ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3953/files - new: https://git.openjdk.java.net/jdk/pull/3953/files/2b975350..d8a1ac00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From lzang at openjdk.java.net Tue May 11 03:26:07 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 03:26:07 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> code refine and typo fix > > I think you still need to undo the JMap.java changes since they are now being handled by #3598 Hi @plummercj , Thanks for your patience reviewing it over and over again! I have undo the JMap.java and sync with latest master. BRs, LIn ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From thomas.stuefe at gmail.com Tue May 11 04:45:51 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 06:45:51 +0200 Subject: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution Message-ID: Hi, May I please have a review for the downport of this patch. I would like to dowport it since it allows us to run gtests which test signal handling on Windows in 11u. This is a precondition for downporting "8257828 SafeFetch may crash if invoked in non-JavaThreads", which is also in work. JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff Original PR: https://git.openjdk.java.net/jdk/pull/1757 The original patch does not apply cleanly due to changes done in GTestWrapper.java in the wake of JEP 387. However, the delta is minimal (just one line). 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff Thank you! Thomas From thomas.stuefe at gmail.com Tue May 11 05:41:38 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 07:41:38 +0200 Subject: [11u] RFR: 8260030: Improve stringStream buffer handling Message-ID: Hi all, I would like to downport the following patch: https://bugs.openjdk.java.net/browse/JDK-8260030 Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff Original review: https://github.com/openjdk/jdk/pull/2160 This patch greatly reduces the number of malloc/free calls done when printing small strings to stringStream: In debug, malloc calls from stringStream ~211000 -> 53000. In a release VM, they drop even further, ~85000 down to just about a 1000 calls. It does so by providing stringStream with a small, in-object array as a backing buffer for small streams, and only switches to C-Heap when this buffer is exhausted, which most of the time won't happen. This also provides code parity with upstream, making future fixes easier to downport. The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) changed stringStream::as_string(), adding the option to return the stream content in C-heap and not as resource area. The differences are limited to that function and superficial. The 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u The patch has been cooking in our internal systems for several weeks now. Thank you! Thomas From thomas.stuefe at gmail.com Tue May 11 06:07:35 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 08:07:35 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads Message-ID: Hi, I'd like reviews for this downport, please. Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Original Review: https://git.openjdk.java.net/jdk/pull/1695 This patch does two things: 1) On Posix platforms it fixes SafeFetch to work in all threads, not only in JavaThreads. In non-JavaThreads before this patch it would crash. The patch is totally trivial. In the signal handler, when handling SafeFetch, there was a condition that Thread != NULL and be a JavaThread. This condition was unnecessary. All SafeFetch handling needs is a valid context. The Patch moves SafeFetch handling out of the is-JavaThread condition. 2) On Windows we did not have the problem; however there is the `Handle_Exception` function handling SafeFetch among other things, which may be called with a non-java thread, but then forcibly casts the Thread* to JavaThread. 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads The original patch does not apply, at all. The reason for this is that we consolidated common functionality of the many cpu+arch signal handlers to one function, in os_posix.cpp. This happened in JDK16 and I do not want to backport this cleanup change to 11. For this patch, it means that the posix-related fixes practically had to be rewritten for each and every signal handler. Each fix is primitive however, since it just moves SafeFetch handling around, but every signal handler is a tiny bit different. I tested this patch for several weeks in our systems on Linux ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. I did not test on 32bit arm. Thanks, Thomas From rehn at openjdk.java.net Tue May 11 08:01:54 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 11 May 2021 08:01:54 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio Looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3919 From aph at openjdk.java.net Tue May 11 09:48:00 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 11 May 2021 09:48:00 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: <7CtCO4fDeY6BLis3eIChxFX-ZGfp21qP9f4SVih7Taw=.ab1d0867-7c3d-4447-bcbb-c676e0e8e140@github.com> On Mon, 10 May 2021 15:52:40 GMT, Gerard Ziemski wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 1708: >> >>> 1706: // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk >>> 1707: // later, so always reserve executable memory right from the start >>> 1708: MACOS_AARCH64_ONLY(| MAP_JIT); >> >> Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug? > > Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS. > > The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again. I get that, but we're disabling a security feature by always mapping memory as (potentially) executable. So, we're trading runtime VM security for convenience in testing, and that strikes me as a bad bargain. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From dholmes at openjdk.java.net Tue May 11 09:52:54 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 09:52:54 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio src/hotspot/share/runtime/thread.cpp line 1621: > 1619: // ok because the call we a returning from already collides > 1620: // with exception handling registers and so there is no issue. > 1621: // (The exception handling path kills call result registers but I'm not clear how you got rid of the check_unsafe_error. They are a special kind of async exception and the scope of checking for them was supposed to be very narrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From martin.doerr at sap.com Tue May 11 11:02:37 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 11:02:37 +0000 Subject: AW: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: Hi Thomas, looks good to me. Thanks for fixing it in 11u. Best regards, Martin Von: hotspot-runtime-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 08:08 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads Hi, I'd like reviews for this downport, please. Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Original Review: https://git.openjdk.java.net/jdk/pull/1695 This patch does two things: 1) On Posix platforms it fixes SafeFetch to work in all threads, not only in JavaThreads. In non-JavaThreads before this patch it would crash. The patch is totally trivial. In the signal handler, when handling SafeFetch, there was a condition that Thread != NULL and be a JavaThread. This condition was unnecessary. All SafeFetch handling needs is a valid context. The Patch moves SafeFetch handling out of the is-JavaThread condition. 2) On Windows we did not have the problem; however there is the `Handle_Exception` function handling SafeFetch among other things, which may be called with a non-java thread, but then forcibly casts the Thread* to JavaThread. 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads The original patch does not apply, at all. The reason for this is that we consolidated common functionality of the many cpu+arch signal handlers to one function, in os_posix.cpp. This happened in JDK16 and I do not want to backport this cleanup change to 11. For this patch, it means that the posix-related fixes practically had to be rewritten for each and every signal handler. Each fix is primitive however, since it just moves SafeFetch handling around, but every signal handler is a tiny bit different. I tested this patch for several weeks in our systems on Linux ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. I did not test on 32bit arm. Thanks, Thomas From thomas.stuefe at gmail.com Tue May 11 11:21:01 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 13:21:01 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: References: Message-ID: Thank you Martin! On Tue, May 11, 2021 at 1:02 PM Doerr, Martin wrote: > Hi Thomas, > > > > looks good to me. Thanks for fixing it in 11u. > > > > Best regards, > > Martin > > > > > > *Von: *hotspot-runtime-dev im > Auftrag von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 08:08 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8257828 SafeFetch may crash if invoked in > non-JavaThreads > > Hi, > > I'd like reviews for this downport, please. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 > Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb > Original Review: https://git.openjdk.java.net/jdk/pull/1695 > > This patch does two things: > > 1) On Posix platforms it fixes SafeFetch to work in all threads, not only > in JavaThreads. In non-JavaThreads before this patch it would crash. > > The patch is totally trivial. In the signal handler, when handling > SafeFetch, there was a condition that Thread != NULL and be a JavaThread. > This condition was unnecessary. All SafeFetch handling needs is a valid > context. The Patch moves SafeFetch handling out of the is-JavaThread > condition. > > 2) On Windows we did not have the problem; however there is the > `Handle_Exception` function handling SafeFetch among other things, which > may be called with a non-java thread, but then forcibly casts the Thread* > to JavaThread. > > 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads > > The original patch does not apply, at all. The reason for this is that we > consolidated common functionality of the many cpu+arch signal handlers to > one function, in os_posix.cpp. This happened in JDK16 and I do not want to > backport this cleanup change to 11. For this patch, it means that the > posix-related fixes practically had to be rewritten for each and every > signal handler. Each fix is primitive however, since it just moves > SafeFetch handling around, but every signal handler is a tiny bit > different. > > I tested this patch for several weeks in our systems on Linux > ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. > > I did not test on 32bit arm. > > Thanks, Thomas > From stuefe at openjdk.java.net Tue May 11 11:48:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 11 May 2021 11:48:13 GMT Subject: RFR: 8266891: Provide a switch to force the class space to a specific location Message-ID: To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time. For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle. ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3969/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3969&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266891 Stats: 58 lines in 2 files changed: 43 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3969/head:pull/3969 PR: https://git.openjdk.java.net/jdk/pull/3969 From rehn at openjdk.java.net Tue May 11 12:13:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 11 May 2021 12:13:33 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn 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 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/e16e2c30..07ddf393 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=00-01 Stats: 15745 lines in 431 files changed: 9555 ins; 3584 del; 2606 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From mli at openjdk.java.net Tue May 11 12:27:24 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 11 May 2021 12:27:24 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler [v2] In-Reply-To: References: Message-ID: > This is trivial change to remove dead code in low memory detector. Hamlin Li 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 remote-tracking branch 'refs/remotes/origin/remove-LowMemoryDetectorDisabler' into remove-LowMemoryDetectorDisabler - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler - remove more dead code. - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler - JDK-8266795: remove dead code LowMemoryDetectorDisabler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3964/files - new: https://git.openjdk.java.net/jdk/pull/3964/files/724a668f..ca68ae74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3964&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3964&range=00-01 Stats: 287 lines in 16 files changed: 227 ins; 33 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3964/head:pull/3964 PR: https://git.openjdk.java.net/jdk/pull/3964 From mli at openjdk.java.net Tue May 11 12:27:24 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 11 May 2021 12:27:24 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler In-Reply-To: References: Message-ID: On Tue, 11 May 2021 01:16:27 GMT, Hamlin Li wrote: > This is trivial change to remove dead code in low memory detector. Thanks David for your detailed review. Just updated as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3964 From stuefe at openjdk.java.net Tue May 11 13:36:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 11 May 2021 13:36:02 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: On Tue, 4 May 2021 19:34:18 GMT, Gerard Ziemski wrote: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. > > Please note, that: > > attempt_reserve_memory_at(executable=true) > commit_memory(executable=false) > > works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. > > Passes Mach5 hs-tier1,2,3,4,5 tests Changes requested by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From stuefe at openjdk.java.net Tue May 11 13:36:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 11 May 2021 13:36:03 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: <8ZjemSUDAyShjwHjwjizOGxmDUDoolRYZaRllwEf4n8=.2a1bc730-6537-432e-97c5-d5790d4dbc74@github.com> On Mon, 10 May 2021 15:52:40 GMT, Gerard Ziemski wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 1708: >> >>> 1706: // On macOS aarch64 MAP_JIT is required if we want to commit an executable chunk >>> 1707: // later, so always reserve executable memory right from the start >>> 1708: MACOS_AARCH64_ONLY(| MAP_JIT); >> >> Is this the right way to do it? Where do we ever map memory we want to use for code generation, but not ask for exec permission? Is that a bug? > > Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS. > > The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again. Hi @gerard-ziemski, please fix the test instead. This would be a security issue, especially since the locations of some of our mappings are very predictable (eg CDS archive). If this is about the "multi-release" test in test_os.cpp (377ff), just disable the exec flag there. I use alternating exec flags to prevent the kernel from folding neighboring mappings, but actually that part is rather linux specific. Arguably we may even completely exclude the test, like I do for AIX already. Its important for Windows, somewhat less important for Linux, and covers other platforms only for completeness sake. Wrt to MAP_JIT , what we do now is the result of long discussions: https://git.openjdk.java.net/jdk/pull/294. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From minqi at openjdk.java.net Tue May 11 14:47:40 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 14:47:40 GMT Subject: RFR: 8266770: Clean pending exception before running dynamic CDS dump Message-ID: Hi, The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8266770: Clean pending exception before running dynamic CDS dump Changes: https://git.openjdk.java.net/jdk/pull/3978/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3978&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266770 Stats: 12 lines in 1 file changed: 7 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3978.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3978/head:pull/3978 PR: https://git.openjdk.java.net/jdk/pull/3978 From gziemski at openjdk.java.net Tue May 11 15:44:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 11 May 2021 15:44:52 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: <8ZjemSUDAyShjwHjwjizOGxmDUDoolRYZaRllwEf4n8=.2a1bc730-6537-432e-97c5-d5790d4dbc74@github.com> References: <8ZjemSUDAyShjwHjwjizOGxmDUDoolRYZaRllwEf4n8=.2a1bc730-6537-432e-97c5-d5790d4dbc74@github.com> Message-ID: On Tue, 11 May 2021 13:32:54 GMT, Thomas Stuefe wrote: >> Inside the hotspot VM code we seem to be doing the right thing, however, in the test, i.e. `test/hotspot/gtest/runtime/test_os.cpp` we ask for regular memory, then try to commit a chunk with elevated exec privileges, which seems to work on all other platforms, except aarch64 macOS. >> >> The alternative, would be to fix the test in question, but since this scenario works fine on all the other platforms, I figured the proposed way to handle it in the VM would be the preferable way to fix it, so future test writers do not need to know this particular platform behavior difference and risk getting it wrong again. > > Hi @gerard-ziemski, > > please fix the test instead. This would be a security issue, especially since the locations of some of our mappings are very predictable (eg CDS archive). > > If this is about the "multi-release" test in test_os.cpp (377ff), just disable the exec flag there. I use alternating exec > flags to prevent the kernel from folding neighboring mappings, but actually that part is rather linux specific. Arguably we may even completely exclude the test, like I do for AIX already. Its important for Windows, somewhat less important for Linux, and covers other platforms only for completeness sake. > > Wrt to MAP_JIT , what we do now is the result of long discussions: https://git.openjdk.java.net/jdk/pull/294. > > Cheers, Thomas I did struggle deciding whether it's a good compromise to make the testing more convenient and consistent among platforms by allowing memory on macOS aarch64 executable right from start, which is why I mentioned that we can (and do) remove that privilege later when we commit it, but after stepping away from this code for a moment and looking at it now, I do agree that it was bad choice. I'll fix the test instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From pchilanomate at openjdk.java.net Tue May 11 15:55:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 11 May 2021 15:55:59 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: On Tue, 11 May 2021 07:58:50 GMT, Robbin Ehn wrote: > Looks good. Thanks Robbin! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From pchilanomate at openjdk.java.net Tue May 11 15:55:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 11 May 2021 15:55:59 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: <5i8lSdtUEf9lptU0OAr8UbpMajzo2j6WQfUjlqPr84k=.9de1e14a-34cc-4e8b-b369-4dbaa417c855@github.com> On Tue, 11 May 2021 09:49:57 GMT, David Holmes wrote: >> Hi, >> >> Please review the following patch which contains the following cleanups: >> >> - Move _suspend_flags from Thread class to JavaThread >> >> - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). >> >> - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. >> >> - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. >> >> Tested in mach5 tiers 1-6. >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/thread.cpp line 1621: > >> 1619: // ok because the call we a returning from already collides >> 1620: // with exception handling registers and so there is no issue. >> 1621: // (The exception handling path kills call result registers but > > I'm not clear how you got rid of the check_unsafe_error. They are a special kind of async exception and the scope of checking for them was supposed to be very narrow. Hi David, > I'm not clear how you got rid of the check_unsafe_error. They are a special kind of async exception and the scope of checking for them was supposed to be very narrow. The only time we call check_and_handle_async_exceptions() with check_unsafe_error=false is in check_special_condition_for_native_trans(), in the transition from native to Java, otherwise that argument is always true. I only moved the check to has_async_exception_condition() so for that particular case we only call check_and_handle_async_exceptions() for non _async_unsafe_access_error cases. That boolean is actually redundant today because in check_special_condition_for_native_trans() we call has_async_exception() first which checks the _suspend_flag bit instead of _special_runtime_exit_condition, and that already only gets set for non _async_unsafe_access_error cases. Then in check_and_handle_async_exceptions() we always check for non _async_unsafe_access_error cases first. Thanks, Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From martin.doerr at sap.com Tue May 11 16:02:10 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 May 2021 16:02:10 +0000 Subject: AW: [11u] RFR: 8260030: Improve stringStream buffer handling In-Reply-To: References: Message-ID: Hi Thomas, looks good. Thanks for backporting. Best regards, Martin Von: hotspot-runtime-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 07:42 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8260030: Improve stringStream buffer handling Hi all, I would like to downport the following patch: https://bugs.openjdk.java.net/browse/JDK-8260030 Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff Original review: https://github.com/openjdk/jdk/pull/2160 This patch greatly reduces the number of malloc/free calls done when printing small strings to stringStream: In debug, malloc calls from stringStream ~211000 -> 53000. In a release VM, they drop even further, ~85000 down to just about a 1000 calls. It does so by providing stringStream with a small, in-object array as a backing buffer for small streams, and only switches to C-Heap when this buffer is exhausted, which most of the time won't happen. This also provides code parity with upstream, making future fixes easier to downport. The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) changed stringStream::as_string(), adding the option to return the stream content in C-heap and not as resource area. The differences are limited to that function and superficial. The 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u The patch has been cooking in our internal systems for several weeks now. Thank you! Thomas From gziemski at openjdk.java.net Tue May 11 16:05:24 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 11 May 2021 16:05:24 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v2] In-Reply-To: References: Message-ID: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. > > Please note, that: > > attempt_reserve_memory_at(executable=true) > commit_memory(executable=false) > > works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. > > Passes Mach5 hs-tier1,2,3,4,5 tests Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: do not expose memory with exec priviledges unless explicitly asked for, fix the test intead to ask for exececutable memory as needed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3865/files - new: https://git.openjdk.java.net/jdk/pull/3865/files/4a9e4a8e..ad3467b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3865&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3865&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3865/head:pull/3865 PR: https://git.openjdk.java.net/jdk/pull/3865 From gziemski at openjdk.java.net Tue May 11 16:05:25 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 11 May 2021 16:05:25 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: On Tue, 4 May 2021 19:34:18 GMT, Gerard Ziemski wrote: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. The way to get "commit_memory(executable=true)" to work is to make the memory chunk executable right from the start at the time we reserve it. > > Please note, that: > > attempt_reserve_memory_at(executable=true) > commit_memory(executable=false) > > works, so we can always downgrade memory by removing its "executable" privilege at the time we commit it some time later. > > Passes Mach5 hs-tier1,2,3,4,5 tests Thank you theRealAph & Thomas for your feedback! I fixed the test instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From ccheung at openjdk.java.net Tue May 11 16:23:16 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 16:23:16 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version Message-ID: Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. Tests: - [x] tier1, 2 ------------- Commit messages: - 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version Changes: https://git.openjdk.java.net/jdk/pull/3983/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266822 Stats: 18 lines in 6 files changed: 4 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From thomas.stuefe at gmail.com Tue May 11 16:28:10 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 11 May 2021 18:28:10 +0200 Subject: [11u] RFR: 8260030: Improve stringStream buffer handling In-Reply-To: References: Message-ID: Thank you Martin! On Tue, May 11, 2021 at 6:02 PM Doerr, Martin wrote: > Hi Thomas, > > > > looks good. Thanks for backporting. > > > > Best regards, > > Martin > > > > > > *Von: *hotspot-runtime-dev im > Auftrag von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 07:42 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8260030: Improve stringStream buffer handling > > Hi all, > > I would like to downport the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8260030 > Original patch: https://github.com/openjdk/jdk/commit/d066f2b0.diff > Original review: https://github.com/openjdk/jdk/pull/2160 > > This patch greatly reduces the number of malloc/free calls done when > printing small strings to stringStream: In debug, malloc calls from > stringStream ~211000 -> 53000. In a release VM, they drop even further, > ~85000 down to just about a 1000 calls. It does so by providing > stringStream with a small, in-object array as a backing buffer for small > streams, and only switches to C-Heap when this buffer is exhausted, which > most of the time won't happen. > > This also provides code parity with upstream, making future fixes easier to > downport. > > The patch does not apply cleanly, since 8238358 (JEP 371: Hidden Classes) > changed stringStream::as_string(), adding the option to return the stream > content in C-heap and not as resource area. The differences are limited to > that function and superficial. > > The 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8260030-improve-stringStream-buffer-handling-11u > > The patch has been cooking in our internal systems for several weeks now. > > Thank you! > > Thomas > From ccheung at openjdk.java.net Tue May 11 16:35:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 16:35:53 GMT Subject: RFR: 8266770: Clean pending exception before running dynamic CDS dump In-Reply-To: References: Message-ID: <4Bl86p6aX2krtRMZF7sT0ro3utUWO09a9UqrvdC5908=.7abfa613-20c5-4b25-8169-1250a9b67479@github.com> On Tue, 11 May 2021 14:39:33 GMT, Yumin Qi wrote: > Hi, > The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: > We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3978 From stuefe at openjdk.java.net Tue May 11 16:37:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 11 May 2021 16:37:53 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:05:24 GMT, Gerard Ziemski wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. >> >> We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > do not expose memory with exec priviledges unless explicitly asked for, fix the test intead to ask for exececutable memory as needed Looks good. Thanks for fixing! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3865 From minqi at openjdk.java.net Tue May 11 16:38:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 16:38:54 GMT Subject: RFR: 8266770: Clean pending exception before running dynamic CDS dump In-Reply-To: <4Bl86p6aX2krtRMZF7sT0ro3utUWO09a9UqrvdC5908=.7abfa613-20c5-4b25-8169-1250a9b67479@github.com> References: <4Bl86p6aX2krtRMZF7sT0ro3utUWO09a9UqrvdC5908=.7abfa613-20c5-4b25-8169-1250a9b67479@github.com> Message-ID: On Tue, 11 May 2021 16:32:39 GMT, Calvin Cheung wrote: >> Hi, >> The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: >> We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > LGTM. @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3978 From dcubed at openjdk.java.net Tue May 11 16:41:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 16:41:57 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio Thumbs up. It would have been helpful to do the code motion as a separate commit so the rename of things from Thread -> JavaThread would be easily comparable from baseline -> commit1. Then do the moves of things from the Thread area of the files to the JavaThread area of the files in commit2. I _think_ I was able to follow and check everything by scrolling back and forth, but I'm not 100% sure. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3919 From iklam at openjdk.java.net Tue May 11 16:45:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 16:45:33 GMT Subject: RFR: 8266770: Clean pending exception before running dynamic CDS dump In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:39:33 GMT, Yumin Qi wrote: > Hi, > The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: > We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Looks good. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3978 From iklam at openjdk.java.net Tue May 11 16:56:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 16:56:56 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:15:08 GMT, Calvin Cheung wrote: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Looks good an trivial. Just a small nit for the comment text. src/hotspot/share/cds/metaspaceShared.cpp line 577: > 575: }; > 576: > 577: // Check if a class or its super class/interface has a version older than 50. How about "Check if a class or any of its supertypes has ...." ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3983 From minqi at openjdk.java.net Tue May 11 17:01:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 17:01:27 GMT Subject: RFR: 8266770: Clean pending exception before running dynamic CDS dump In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:42:22 GMT, Ioi Lam wrote: >> Hi, >> The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: >> We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Looks good. @iklam thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3978 From minqi at openjdk.java.net Tue May 11 17:01:28 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 17:01:28 GMT Subject: Integrated: 8266770: Clean pending exception before running dynamic CDS dump In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:39:33 GMT, Yumin Qi wrote: > Hi, > The change is simple for reorder the exception cleaning in JavaThread::invoke_shutdown_hooks: > We should clean the pending exception before calling into MetaspaceShared::link_and_cleanup_shared_classes at dynamic dump, or it will cause it fail. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: ac0287fd Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/ac0287fd73997c510ee41c9a42dc48261e7d5ee7 Stats: 12 lines in 1 file changed: 7 ins; 5 del; 0 mod 8266770: Clean pending exception before running dynamic CDS dump Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3978 From vlivanov at openjdk.java.net Tue May 11 17:18:00 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 11 May 2021 17:18:00 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed [v2] In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Adjust year in copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3879/files - new: https://git.openjdk.java.net/jdk/pull/3879/files/32ee955e..78fb2851 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3879&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3879&range=00-01 Stats: 16 lines in 16 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3879/head:pull/3879 PR: https://git.openjdk.java.net/jdk/pull/3879 From vlivanov at openjdk.java.net Tue May 11 17:18:00 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 11 May 2021 17:18:00 GMT Subject: RFR: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) Thanks for the reviews, Harold, Coleen, Mikhailo, and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/3879 From vlivanov at openjdk.java.net Tue May 11 17:18:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 11 May 2021 17:18:01 GMT Subject: Integrated: 8208237: Re-examine defmeth tests and update as needed In-Reply-To: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> References: <6AbbaHOr8nLlrl9w-GMAl3gLqYjSB1I77UDJQGTZp3Q=.14360b44-80c2-413c-b930-8559091ecfa8@github.com> Message-ID: On Wed, 5 May 2021 10:38:18 GMT, Vladimir Ivanov wrote: > Some test cleanups: > - removed all `@KnownFailure` > - narrowed expected error types in some cases > - fixed private method invocation tests in reflection mode (got rid of `NoSuchMethodError`s in reflection mode) > - introduced `TesterBuilder::new_()` to let the tests precisely describe the intent > - some other minor cleanups > > Testing: > - [x] defmeth tests > - [x] hs-tier5 - hs-tier6 (include defmeth tests) This pull request has now been integrated. Changeset: acf02ed5 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/acf02ed5533e25ec572d18ff874a241860c66bed Stats: 679 lines in 20 files changed: 132 ins; 356 del; 191 mod 8208237: Re-examine defmeth tests and update as needed Reviewed-by: hseigel, lfoltan, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3879 From ccheung at openjdk.java.net Tue May 11 17:35:27 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 17:35:27 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:53:34 GMT, Ioi Lam wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > src/hotspot/share/cds/metaspaceShared.cpp line 577: > >> 575: }; >> 576: >> 577: // Check if a class or its super class/interface has a version older than 50. > > How about "Check if a class or any of its supertypes has ...." @iklam Thanks for the review. I'll update the comment before integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From ccheung at openjdk.java.net Tue May 11 17:39:52 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 17:39:52 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v2] In-Reply-To: References: Message-ID: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3983/files - new: https://git.openjdk.java.net/jdk/pull/3983/files/3cb3825d..6ae1e11c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From ccheung at openjdk.java.net Tue May 11 17:47:33 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 17:47:33 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v3] In-Reply-To: References: Message-ID: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3983/files - new: https://git.openjdk.java.net/jdk/pull/3983/files/6ae1e11c..1b90f8c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From minqi at openjdk.java.net Tue May 11 17:47:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 17:47:38 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v2] In-Reply-To: References: Message-ID: <844LmB-zubZcrswsoZuwY3lITlEOFQ8slLb1WQqboSw=.0cdeb1d2-83c7-400e-ae4e-04a6e903873b@github.com> On Tue, 11 May 2021 17:39:52 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update comment Should we move has_old_class_version to Klass or InstanceKlass? ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From coleenp at openjdk.java.net Tue May 11 17:59:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 11 May 2021 17:59:57 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v3] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:47:33 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update comment Calvin, thank you for doing this. I agree with Yumin that this seems to be a function of InstanceKlass. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From joe.darcy at oracle.com Tue May 11 18:11:26 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 11 May 2021 11:11:26 -0700 Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: <460f262d-4798-4df2-4eb2-130eec72ec29@oracle.com> References: <460f262d-4798-4df2-4eb2-130eec72ec29@oracle.com> Message-ID: On 5/10/2021 5:20 PM, David Holmes wrote: > On 11/05/2021 5:14 am, Harold Seigel wrote: >> On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >> >>>> Please review these VM changes in support of JEP 306: Restore >>>> Always-Strict Floating-Point Semantics. >>>> >>>> JEP 306 is considering the following changes to the JVMS: >>>> >>>> 1) Require "strict" floating-point evaluation in all circumstances. >>>> 2) For class file version 61 and higher, undefine ACC_STRICT, >>>> moving that bit position back to undefined for methods. For class >>>> file versions, 46 through, ACC_STRICT would remain a defined modifier. >>>> >>>> Since all floating-point evaluation is done strictly, a modifier >>>> bit is not needed to indicate this anymore. There are a few >>>> mandated modifier checks when ACC_STRICT is defined, such as not >>>> allowing an "abstract strictfp" method. These checks in >>>> classFileParser are now conditional on the class file version. >>>> >>>> The tests verify? "abstract strictfp" triggers a ClassFormatError? >>>> for version 60 and does not trigger an error or exception for >>>> version 61. (As an undefined bit in version 61, the VM is supposed >>>> to ignore it.) >>>> >>>> FYI, the javac and core libs portions of JEP 306 are out for review >>>> under https://github.com/openjdk/jdk/pull/3831. >>>> >>>> The HotSpot and javac/core libs parts of JEP 306 are independent in >>>> that neither relies on the other: >>>> ? * javac will not output class files which expose the difference >>>> in class parsing behavior; the ACC_STRICT modifier will not be set >>>> in any version 61 class file emitted by javac. >>>> ? *? since HotSpot already does all floating-point evaluation >>>> strictly, no changes are needed to support strict evaluation. >>> >>> Joe Darcy has updated the pull request with a new target base due to >>> a merge or a rebase. The incremental webrev excludes the unrelated >>> changes brought in by the merge/rebase. The pull request contains >>> three additional commits since the last revision: >>> >>> ? - Merge branch 'master' into 8266530 >>> ? - Respond to review feedback. >>> ? - 8266530: HotSpot changes for JEP 306 >> >> Hi Joe, >> If the code that calls is_strict() (and other code that looks at >> ACC_STRICT) is no longer needed then it should be removed. Otherwise, >> that code should be changed to also check if ik->major_version() >= 61. > > Right - the normal process would be to update the code based on > is_strict() always returning true thus eliding it, but retaining the > code it causes to be called. > I've pushed another changeset which defines is_strict in method.hpp as true under IA32. If IA32 covers all platforms that could use the x87 FPU stack, this should be sufficient for correctness. Thanks, -Joe From darcy at openjdk.java.net Tue May 11 18:11:58 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 11 May 2021 18:11:58 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v4] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Respond to review feedback. - 8266530: HotSpot changes for JEP 306 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/f610ba6e..786912c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=02-03 Stats: 12459 lines in 302 files changed: 7433 ins; 2797 del; 2229 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From dcubed at openjdk.java.net Tue May 11 19:12:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 19:12:01 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 12:13:33 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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 8265753 > - Removed manual transitions Thumbs up on the over all logic. I only have minor nits and suggestions. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 242: > 240: if (self->is_Java_thread()) { > 241: JavaThread* jt = self->as_Java_thread(); > 242: guarantee(jt->thread_state() == _thread_in_native, "invariant"); Thanks for making this a guarantee()! There is an existing assert() about this in: ThreadInVMfromNative -> trans() -> transition_from_native() so it doesn't have to be there for forever. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320: > 318: // JavaThreads will enter here with state _thread_in_native. > 319: void JvmtiRawMonitor::raw_enter(Thread* self) { > 320: // TODO Atomic::load on _owner field Why is this still a TODO? src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42: > 40: // Important note: > 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM > 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint nit typo: s/e.g./e.g.,/ nit typo: s/tranisition/transition/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43: > 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM > 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint > 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread, nit typo: s/VM thread/the VM thread/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > 46: // The rules are: > 47: // - We must never safepoint poll if raw monitor is owned. > 48: // - We may safepoint poll before it is owned and after it have been released. nit typo: s/have been/has been/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > 50: // native for all operations. However we need to honor suspend request, not > 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened > 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe nit typo: s/suspend request/a suspend request/ nit typo: s/Honoring suspened/Honoring a suspend request/ nit typo: s/interrupt flag/the interrupt flag/ (You'll probably want to reformat the changed lines a bit.) src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206: > 204: ~ThreadInVMfromNative() { > 205: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); > 206: _thread->set_thread_state(_thread_in_native); You're losing the assertion that we're transitioning from `_thread_in_vm` to `_thread_in_native` here. Although, the constructor did verify that we were in `_thread_in_native` when we transitioned to `_thread_in_vm` so at least the first half is still verified. Can you an assertion that we're in `_thread_in_vm` here? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: > 228: }; > 229: > 230: template When you mentioned doing this with templates, I was having nightmares, but this one is not bad at all... src/hotspot/share/runtime/objectMonitor.cpp line 313: > 311: if (current->is_suspended()) { > 312: _om->_recursions = 0; > 313: _om->_succ = NULL; Please add a comment after this line: // Don't need a full fence after clearing successor here because of the call to exit(). src/hotspot/share/runtime/objectMonitor.cpp line 325: > 323: OrderAccess::fence(); // always do a full fence when successor is cleared > 324: } > 325: _om_exit = true; Hmmm... `_om_exit` flag is misnamed here since you're "only" clearing the successor. Update: Now I see that the ClearSuccOnSuspend class is subclassed from the ExitOnSuspend, but I still find that flag a bit confusing. src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _om_exit; Instead of `_om_exit` maybe this should be more generic? Perhaps `_om_op_done` or something like that? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From coleenp at openjdk.java.net Tue May 11 19:14:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 11 May 2021 19:14:16 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v2] In-Reply-To: <844LmB-zubZcrswsoZuwY3lITlEOFQ8slLb1WQqboSw=.0cdeb1d2-83c7-400e-ae4e-04a6e903873b@github.com> References: <844LmB-zubZcrswsoZuwY3lITlEOFQ8slLb1WQqboSw=.0cdeb1d2-83c7-400e-ae4e-04a6e903873b@github.com> Message-ID: <9NjnXPo7RTSNhRftmA6-d7nwUEMbxidIehQzzstBWDo=.2d1bbdbd-112c-417d-85cf-87c111451f72@github.com> On Tue, 11 May 2021 17:42:02 GMT, Yumin Qi wrote: > Should we move has_old_class_version to Klass or InstanceKlass? InstanceKlass makes more sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From cjplummer at openjdk.java.net Tue May 11 19:38:04 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 11 May 2021 19:38:04 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23] In-Reply-To: References: Message-ID: <2T6LlZ9PbwPuy5f1_WfMmboNDcHimJ2-dhPvRMH_qlw=.107aa7b8-5d03-47b0-9687-e307f90d30d5@github.com> On Tue, 11 May 2021 03:19:05 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad heapDumper.hpp needs a copyright update. Otherwise the changes look good. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2261 From ccheung at openjdk.java.net Tue May 11 19:38:18 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 19:38:18 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v3] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:57:15 GMT, Coleen Phillimore wrote: > Calvin, thank you for doing this. I agree with Yumin that this seems to be a function of InstanceKlass. Coleen and Yumin, Thanks for the suggestion. I've made the code changes. Running some tests before posting another webrev. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From stefank at openjdk.java.net Tue May 11 19:52:10 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 11 May 2021 19:52:10 GMT Subject: RFR: 8266904: Use function pointer typedefs in OopOopIterateDispatch Message-ID: <-VkwrwvHctT2nKbO8Zc1vFsxG-2KPcZzhME-5f5w3OU=.22bab745-85ff-4ff0-becc-82ef47ca650f@github.com> The way our OopIterateClosures are devirtualized is quite complex. I think we can lower the complexity a tiny bit by using a function pointer typedef. ------------- Commit messages: - 8266904: Use function pointer typedefs in OopOopIterateDispatch Changes: https://git.openjdk.java.net/jdk/pull/3986/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3986&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266904 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3986.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3986/head:pull/3986 PR: https://git.openjdk.java.net/jdk/pull/3986 From pchilanomate at openjdk.java.net Tue May 11 20:25:07 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 11 May 2021 20:25:07 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: <2hNrDxNtDuFNjkQ8KNjgddqAPs-uEwATL7sWW8a8GxE=.1892e770-a8eb-4ea6-9b60-c20227fc4159@github.com> On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio Hi Dan, > Thumbs up. > > It would have been helpful to do the code motion as a separate commit > so the rename of things from Thread -> JavaThread would be easily > comparable from baseline -> commit1. Then do the moves of things > from the Thread area of the files to the JavaThread area of the files in > commit2. Right, I didn't thought of that. I'll keep it in mind for future changes. If you want I could try to do it for this one but I would have to force push to my fork after the changes (not sure if it will be handled correctly here). > I _think_ I was able to follow and check everything by scrolling back > and forth, but I'm not 100% sure. Thanks for the review Dan! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From dcubed at openjdk.java.net Tue May 11 20:38:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 20:38:38 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: <-wh7vd6OwMpZ0wUW0wiPNFJSqU_kht37MQLtbR0QxOc=.e413084c-17f2-4395-9e96-aad70f571646@github.com> On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio No need to try and redo the PR by force pushing. I'm good with the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From ccheung at openjdk.java.net Tue May 11 20:42:17 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 20:42:17 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v4] In-Reply-To: References: Message-ID: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: move the has_old_class_version function to InstanceKlass ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3983/files - new: https://git.openjdk.java.net/jdk/pull/3983/files/1b90f8c4..cb45e49b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=02-03 Stats: 61 lines in 7 files changed: 26 ins; 26 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From sspitsyn at openjdk.java.net Tue May 11 21:03:56 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 11 May 2021 21:03:56 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2379 From iklam at openjdk.java.net Tue May 11 21:05:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 21:05:09 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v4] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 20:42:17 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > move the has_old_class_version function to InstanceKlass Changes requested by iklam (Reviewer). src/hotspot/share/oops/instanceKlass.cpp line 2583: > 2581: return true; > 2582: } > 2583: if (has_old_class_version(ik->java_super())) { I think it's better to change this static method into an instance method, so you can call `klass->has_old_class_version()`. You'd also need to change the above "if" to if (ik->java_super() != NULL && ik->super->has_old_class_version()) { ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From coleenp at openjdk.java.net Tue May 11 21:05:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 11 May 2021 21:05:10 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v4] In-Reply-To: References: Message-ID: <59-X3sb8raJpMI74BBebyKnfYoJjOcvayP0XUoOzXGc=.b27adb59-6038-41f1-99d0-c52a7d723549@github.com> On Tue, 11 May 2021 21:00:10 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> move the has_old_class_version function to InstanceKlass > > src/hotspot/share/oops/instanceKlass.cpp line 2583: > >> 2581: return true; >> 2582: } >> 2583: if (has_old_class_version(ik->java_super())) { > > I think it's better to change this static method into an instance method, so you can call `klass->has_old_class_version()`. You'd also need to change the above "if" to > > > if (ik->java_super() != NULL && ik->super->has_old_class_version()) { Yes. I agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From david.holmes at oracle.com Tue May 11 21:22:56 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 07:22:56 +1000 Subject: RFR: 8266530: HotSpot changes for JEP 306 In-Reply-To: References: <1650764549.2015442.1620250026844.JavaMail.zimbra@u-pem.fr> Message-ID: Hi John, Thanks for the detailed response on this. Notwithstanding that, I still believe the initial approach here should be a normal deprecation style process for the VM. Effectively in 17 ACC_STRICT is deprecated: it is implicitly applied to all methods but need not be explicitly applied; if explicitly applied it has the same rules as have existed to date. Then in 17+N ACC_STRICT use is considered an error and is rejected always. Then in 17+N+M we can start reusing the bit value for ACC_MUMBLE. In terms of the JVMS we don't undefine ACC_STRICT at this stage, we just update its semantics. Just my 2c. Cheers, David On 11/05/2021 6:42 am, John Rose wrote: > On May 5, 2021, at 2:27 PM, Remi Forax > wrote: >> >> If possible, I would prefer ACC_STRICT to be banned instead of being >> ignored, for version >= 51. > > I sympathize with this, and I had hoped (when Joe set out > on this work) that the JVMS would cooperate. ?But it doesn?t, > in the most straightforward interpretation. ?(And yes, we > are making new interpretations here because we are on > new ground. ?And it is natural to get here after a quarter > century; the question is where to aim for the next quarter > century.) > > > On May 7, 2021, at 3:47 AM, David Holmes > wrote: >> >> I'm not sure it makes sense to allow ACC_STRICT to suddenly appear >> where it would otherwise be illegal. ?? > > This does seem surprising, but it is a clean consequence > of the stated goal of removing the access modifier from > the JVM specification. ?As soon as 0x0800 (ACC_STRICT) > becomes an undefined flag, non-zero settings become > legal in all cases. ?However paradoxical, this follows > from the JVMS language which Joe quotes. ?I?d like > to change that behavior eventually, but that would be > a separate step. > > On May 5, 2021, at 2:51 PM, Joe Darcy > wrote: >> >> "All bits of the access_flags item not assigned in Table 4.6-A are >> reserved for future use. They should be set to zero in generated class >> files and should be ignored by Java Virtual Machine implementations. > > The JVMS discourages but does not disallows the setting of > undefined class file bits. ?The simplest removal of ACC_STRICT > will revert it to the status of an undefined bit, which can be > set to nonzero but? ?should be set to zero?. ?Or else?? There > is no ?or else? specified, therefore we can?t spring a new error > on the user. > > I think we may need a JEP to define stricter rules for undefined > modifiers. ?(And maybe more JEP work for other undefined > classfile states, though a quick search doesn?t reveal any good > candidates.) ?The JEP?s mandated checking can have well-defined > interactions with configuration flags, such as preview or > experimental modes, or even a permanent ?strict? vs. ?lax? > JVM flag. > > Then we can more confidently extend those undefined or > ignored `access_flag` bits, to well-defined bits. ?At that > point we can recycle the bit position occupied by > 0x0800 (ACC_STRICT), since we will then be confident > there will be no undiagnosed noise in that unused channel. > > It might seem reasonable to, at least, anticipate such an > improvement to the spec, in the one case of ACC_STRICT, > and require JVMs to throw an error on the vacated bit. > > Indeed, this would be another ?interpretation? of the > intent of theJVM spec, in this new case of removing the > definition of a modifier bit. ?But it would add spec > complexity to the JVM (after strictfp removal) for > little gain: ?The special treatment of the vacated bit > would, indeed, allow it to be recycled sooner, and > lagging tools would be diagnosed more easily. ?But > that?s not enough benefit, IMO, to remove strictfp > and *then* make its vacated bit position into sacred > ground that is different from that in other bit positions. > > (A counter argument is that, since we have insisted > that class file generation tools, to date, be able to emit > ACC_STRICT?in certain circumstances, we should > help them back away from that behavior by having the > JVM reject such outputs. ?But this can be handled by > a different tool or tool mode, better than having the > JVM spec centralize such checks.) > > So I think on balance it?s best to adjust the JVM spec > now to appear as if ACC_STRICT?had never happened > (relative to up-rev class files), and consider solving the > wider problem of undefined modifiers, as a separate line > of work. > > ? John > From ccheung at openjdk.java.net Tue May 11 22:07:40 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 22:07:40 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v5] In-Reply-To: References: Message-ID: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: convert has_old_class_version to an instance method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3983/files - new: https://git.openjdk.java.net/jdk/pull/3983/files/cb45e49b..ce372118 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=03-04 Stats: 18 lines in 6 files changed: 0 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From minqi at openjdk.java.net Tue May 11 22:21:56 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 11 May 2021 22:21:56 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 22:07:40 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > convert has_old_class_version to an instance method LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3983 From coleenp at openjdk.java.net Tue May 11 22:21:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 11 May 2021 22:21:57 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 22:07:40 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > convert has_old_class_version to an instance method Thank you for making this change! src/hotspot/share/oops/instanceKlass.cpp line 2576: > 2574: // retrieved during dump time. > 2575: // Verification of archived old classes will be performed during run time. > 2576: bool InstanceKlass::has_old_class_version() { very small nit: Can you make this function 'const' ? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3983 From iklam at openjdk.java.net Tue May 11 22:21:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 22:21:58 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 22:07:40 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > convert has_old_class_version to an instance method LGTM. Just a small nit. I think `has_old_class_version` can be declared as `const`. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3983 From ccheung at openjdk.java.net Tue May 11 22:47:44 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 22:47:44 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version [v6] In-Reply-To: References: Message-ID: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: declare has_old_class_version as a const method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3983/files - new: https://git.openjdk.java.net/jdk/pull/3983/files/ce372118..974e6c58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=04-05 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 PR: https://git.openjdk.java.net/jdk/pull/3983 From david.holmes at oracle.com Tue May 11 23:20:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 09:20:04 +1000 Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: References: <460f262d-4798-4df2-4eb2-130eec72ec29@oracle.com> Message-ID: <75b4d011-d4ae-060e-5f05-d2ed492d8a20@oracle.com> Hi Joe, On 12/05/2021 4:11 am, Joe Darcy wrote: > On 5/10/2021 5:20 PM, David Holmes wrote: >> On 11/05/2021 5:14 am, Harold Seigel wrote: >>> On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >>> >>>>> Please review these VM changes in support of JEP 306: Restore >>>>> Always-Strict Floating-Point Semantics. >>>>> >>>>> JEP 306 is considering the following changes to the JVMS: >>>>> >>>>> 1) Require "strict" floating-point evaluation in all circumstances. >>>>> 2) For class file version 61 and higher, undefine ACC_STRICT, >>>>> moving that bit position back to undefined for methods. For class >>>>> file versions, 46 through, ACC_STRICT would remain a defined modifier. >>>>> >>>>> Since all floating-point evaluation is done strictly, a modifier >>>>> bit is not needed to indicate this anymore. There are a few >>>>> mandated modifier checks when ACC_STRICT is defined, such as not >>>>> allowing an "abstract strictfp" method. These checks in >>>>> classFileParser are now conditional on the class file version. >>>>> >>>>> The tests verify? "abstract strictfp" triggers a ClassFormatError >>>>> for version 60 and does not trigger an error or exception for >>>>> version 61. (As an undefined bit in version 61, the VM is supposed >>>>> to ignore it.) >>>>> >>>>> FYI, the javac and core libs portions of JEP 306 are out for review >>>>> under https://github.com/openjdk/jdk/pull/3831. >>>>> >>>>> The HotSpot and javac/core libs parts of JEP 306 are independent in >>>>> that neither relies on the other: >>>>> ? * javac will not output class files which expose the difference >>>>> in class parsing behavior; the ACC_STRICT modifier will not be set >>>>> in any version 61 class file emitted by javac. >>>>> ? *? since HotSpot already does all floating-point evaluation >>>>> strictly, no changes are needed to support strict evaluation. >>>> >>>> Joe Darcy has updated the pull request with a new target base due to >>>> a merge or a rebase. The incremental webrev excludes the unrelated >>>> changes brought in by the merge/rebase. The pull request contains >>>> three additional commits since the last revision: >>>> >>>> ? - Merge branch 'master' into 8266530 >>>> ? - Respond to review feedback. >>>> ? - 8266530: HotSpot changes for JEP 306 >>> >>> Hi Joe, >>> If the code that calls is_strict() (and other code that looks at >>> ACC_STRICT) is no longer needed then it should be removed. Otherwise, >>> that code should be changed to also check if ik->major_version() >= 61. >> >> Right - the normal process would be to update the code based on >> is_strict() always returning true thus eliding it, but retaining the >> code it causes to be called. >> > I've pushed another changeset which defines is_strict in method.hpp as > true under IA32. If IA32 covers all platforms that could use the x87 FPU > stack, this should be sufficient for correctness. I'm not seeing that changeset in the PR ?? But it sounds insufficient. Every expression using is_strict() should replace is_strict() with true and then collapse the code appropriately. Cheers, David > Thanks, > > -Joe > From dcubed at openjdk.java.net Tue May 11 23:24:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:24:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> Message-ID: On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary "@library /test/lib". > > HI Dan, > > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. > > Cheers, > David @dholmes-ora - Sorry I missed this comment: > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. This test stresses getThreadInfo() and ThreadInfo.getLockOwnerName() as a JavaThread is exiting. Similar to other stress tests that I wrote for M&M in the Thread-SMR project, but this one is targeting getting the lock owner name as the lock owner thread is exiting. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From joe.darcy at oracle.com Tue May 11 23:27:25 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 11 May 2021 16:27:25 -0700 Subject: RFR: 8266530: HotSpot changes for JEP 306 [v3] In-Reply-To: <75b4d011-d4ae-060e-5f05-d2ed492d8a20@oracle.com> References: <460f262d-4798-4df2-4eb2-130eec72ec29@oracle.com> <75b4d011-d4ae-060e-5f05-d2ed492d8a20@oracle.com> Message-ID: Forgot to commit before my last push, *sigh*, just corrected. Thanks, -Joe On 5/11/2021 4:20 PM, David Holmes wrote: > Hi Joe, > > On 12/05/2021 4:11 am, Joe Darcy wrote: >> On 5/10/2021 5:20 PM, David Holmes wrote: >>> On 11/05/2021 5:14 am, Harold Seigel wrote: >>>> On Fri, 7 May 2021 04:58:22 GMT, Joe Darcy wrote: >>>> >>>>>> Please review these VM changes in support of JEP 306: Restore >>>>>> Always-Strict Floating-Point Semantics. >>>>>> >>>>>> JEP 306 is considering the following changes to the JVMS: >>>>>> >>>>>> 1) Require "strict" floating-point evaluation in all circumstances. >>>>>> 2) For class file version 61 and higher, undefine ACC_STRICT, >>>>>> moving that bit position back to undefined for methods. For class >>>>>> file versions, 46 through, ACC_STRICT would remain a defined >>>>>> modifier. >>>>>> >>>>>> Since all floating-point evaluation is done strictly, a modifier >>>>>> bit is not needed to indicate this anymore. There are a few >>>>>> mandated modifier checks when ACC_STRICT is defined, such as not >>>>>> allowing an "abstract strictfp" method. These checks in >>>>>> classFileParser are now conditional on the class file version. >>>>>> >>>>>> The tests verify? "abstract strictfp" triggers a ClassFormatError >>>>>> for version 60 and does not trigger an error or exception for >>>>>> version 61. (As an undefined bit in version 61, the VM is >>>>>> supposed to ignore it.) >>>>>> >>>>>> FYI, the javac and core libs portions of JEP 306 are out for >>>>>> review under https://github.com/openjdk/jdk/pull/3831. >>>>>> >>>>>> The HotSpot and javac/core libs parts of JEP 306 are independent >>>>>> in that neither relies on the other: >>>>>> ? * javac will not output class files which expose the difference >>>>>> in class parsing behavior; the ACC_STRICT modifier will not be >>>>>> set in any version 61 class file emitted by javac. >>>>>> ? *? since HotSpot already does all floating-point evaluation >>>>>> strictly, no changes are needed to support strict evaluation. >>>>> >>>>> Joe Darcy has updated the pull request with a new target base due >>>>> to a merge or a rebase. The incremental webrev excludes the >>>>> unrelated changes brought in by the merge/rebase. The pull request >>>>> contains three additional commits since the last revision: >>>>> >>>>> ? - Merge branch 'master' into 8266530 >>>>> ? - Respond to review feedback. >>>>> ? - 8266530: HotSpot changes for JEP 306 >>>> >>>> Hi Joe, >>>> If the code that calls is_strict() (and other code that looks at >>>> ACC_STRICT) is no longer needed then it should be removed. >>>> Otherwise, that code should be changed to also check if >>>> ik->major_version() >= 61. >>> >>> Right - the normal process would be to update the code based on >>> is_strict() always returning true thus eliding it, but retaining the >>> code it causes to be called. >>> >> I've pushed another changeset which defines is_strict in method.hpp >> as true under IA32. If IA32 covers all platforms that could use the >> x87 FPU stack, this should be sufficient for correctness. > > I'm not seeing that changeset in the PR ?? > > But it sounds insufficient. Every expression using is_strict() should > replace is_strict() with true and then collapse the code appropriately. > > Cheers, > David > >> Thanks, >> >> -Joe >> From dcubed at openjdk.java.net Tue May 11 23:28:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:28:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> Message-ID: <7n0D4JR-B2bxToSWtJ361mu3b_xT5Zfmo9JDsmRISao=.4b15a470-2dd3-460b-884b-3e16925acb87@github.com> On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary "@library /test/lib". > > HI Dan, > > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. > > Cheers, > David @dholmes-ora also sent the comment in email but it didn't seem to show up in this PR: > Hmmm... this is a legacy style/approach that is not necessary any more. > If the test fails it should throw an exception from the main thread and > that will produce a non-zero exit value. I think seeing this legacy style in > new tests will just confuse people. I agree. In particular this legacy style approach with exit_delta == 95 is for VMTestbase tests and this new test is not part of the VMTestbase test suite. I'm fixing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From darcy at openjdk.java.net Tue May 11 23:31:20 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 11 May 2021 23:31:20 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v5] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Make methods strict on IA32. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/786912c2..5eb74621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=03-04 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From coleenp at openjdk.java.net Tue May 11 23:34:14 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 11 May 2021 23:34:14 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" [v2] In-Reply-To: References: Message-ID: <4IVcdgWmzH9AMSX8EKTJ3gjQMrJsehLQSlAQe8emOgk=.961d41eb-8244-4368-a5f6-b186bb8b3c45@github.com> On Sun, 9 May 2021 22:10:24 GMT, David Holmes wrote: >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Update test per Coleen's comments: > - need to add java.security.manager=allow just to be safe > - simplify logic to read classfile from disk (ref ClassUnloadCommon.getClassData()) > - Merge branch 'master' into 8261395-nestmember > - Per Coleen: Reverse arguments order for has_nest_member so we can revert the introduction of "current". > - Fix typo > - Completely simpified the has_nest_member check to only use names. > This avoids any possibility of class loading or executing any Java > code and removes all possibility of exceptions in this part of the > nestmate verification process. > - Add test > - Tweak logging message > - 8261395: C1 crash "cannot make java calls from the native compiler" > - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. Looks good to me! test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 80: > 78: try { > 79: String clzFile = name.replaceAll("\\.", "/") + ".class"; > 80: byte[] buff = getResourceAsStream(clzFile).readAllBytes(); There's a ClassUnloadCommon.getBytesForClass(name) that you could have called that does essentially what these two lines do. Maybe it's different enough to have this, so it's up to you to change it. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3913 From dcubed at openjdk.java.net Tue May 11 23:34:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:34:29 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Drop exit_delta and the VMTestbase style of exiting on test failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/bac63a79..771dafee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From dholmes at openjdk.java.net Tue May 11 23:40:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 23:40:12 GMT Subject: RFR: 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh Message-ID: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> Please see the bug report for detailed description of the issue. The simple fix for the test is to disable inlining of the lock() method (something which I think the existing MaxInlineLevel flags were trying to achieve but didn't). Testing: - before fix I ran the test 50x on linux-x64, macos-x64 and macos-aarch64 product and fastdebug -> 300 failures - after: 300 successes Thanks, David ------------- Commit messages: - 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh Changes: https://git.openjdk.java.net/jdk/pull/3989/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3989&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231031 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3989/head:pull/3989 PR: https://git.openjdk.java.net/jdk/pull/3989 From dcubed at openjdk.java.net Tue May 11 23:49:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:49:01 GMT Subject: RFR: 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh In-Reply-To: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> References: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> Message-ID: <_uOLXHo4Pjfs-5BjAd6nd5xqqdjDZq00SLlnJgUMg1w=.bbb68467-1195-4dc1-8c99-92e71398f256@github.com> On Tue, 11 May 2021 23:32:24 GMT, David Holmes wrote: > Please see the bug report for detailed description of the issue. The simple fix for the test is to disable inlining of the lock() method (something which I think the existing MaxInlineLevel flags were trying to achieve but didn't). > > Testing: > - before fix I ran the test 50x on linux-x64, macos-x64 and macos-aarch64 product and fastdebug -> 300 failures > - after: 300 successes > > Thanks, > David Congrats on chasing this one to ground! Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3989 From iklam at openjdk.java.net Tue May 11 23:49:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 23:49:11 GMT Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" [v2] In-Reply-To: References: Message-ID: On Sun, 9 May 2021 22:10:24 GMT, David Holmes wrote: >> If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. >> >> After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. >> >> @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. >> @coleenp also contributed to an earlier version of the fix. >> >> Thanks to both Coleen and Ioi for their insights, discussions and contributions. >> >> Testing: >> - the new test >> - tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Update test per Coleen's comments: > - need to add java.security.manager=allow just to be safe > - simplify logic to read classfile from disk (ref ClassUnloadCommon.getClassData()) > - Merge branch 'master' into 8261395-nestmember > - Per Coleen: Reverse arguments order for has_nest_member so we can revert the introduction of "current". > - Fix typo > - Completely simpified the has_nest_member check to only use names. > This avoids any possibility of class loading or executing any Java > code and removes all possibility of exceptions in this part of the > nestmate verification process. > - Add test > - Tweak logging message > - 8261395: C1 crash "cannot make java calls from the native compiler" > - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From ccheung at openjdk.java.net Tue May 11 23:55:56 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 11 May 2021 23:55:56 GMT Subject: Integrated: 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:15:08 GMT, Calvin Cheung wrote: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > Tests: > - [x] tier1, 2 This pull request has now been integrated. Changeset: 57c6ba6e Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/57c6ba6e6b1c1bf30dcfffee873790dfc4fa511a Stats: 54 lines in 7 files changed: 23 ins; 22 del; 9 mod 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means Reviewed-by: iklam, minqi, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From mli at openjdk.java.net Wed May 12 01:07:17 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 12 May 2021 01:07:17 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 12:27:24 GMT, Hamlin Li wrote: >> This is trivial change to remove dead code in low memory detector. > > Hamlin Li 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 remote-tracking branch 'refs/remotes/origin/remove-LowMemoryDetectorDisabler' into remove-LowMemoryDetectorDisabler > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - remove more dead code. > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - JDK-8266795: remove dead code LowMemoryDetectorDisabler Seems the build failure is not related to this change. ''' 2021-05-11T13:21:17.0861973Z Err:27 https://packages.microsoft.com/repos/azure-cli focal Release 2021-05-11T13:21:17.0863392Z Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 13.82.67.141 443] 2021-05-11T13:21:50.1858001Z Err:28 https://packages.microsoft.com/ubuntu/20.04/prod focal Release 2021-05-11T13:21:50.1859811Z Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 13.82.67.141 443] 2021-05-11T13:21:56.7524970Z Reading package lists... 2021-05-11T13:21:56.7679502Z E: The repository 'https://packages.microsoft.com/repos/azure-cli focal Release' no longer has a Release file. 2021-05-11T13:21:56.7681552Z E: The repository 'https://packages.microsoft.com/ubuntu/20.04/prod focal Release' no longer has a Release file. 2021-05-11T13:21:56.7697849Z ##[error]Process completed with exit code 100. ''' ------------- PR: https://git.openjdk.java.net/jdk/pull/3964 From mli at openjdk.java.net Wed May 12 01:21:01 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 12 May 2021 01:21:01 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com> <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com> <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com> Message-ID: On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> improve jcmd GC.class_histogram to support parallel > > For jmap -histo we have: > > parallel= parallel threads number for heap iteration: > parallel=0 default behavior, use predefined number of threads > parallel=1 disable parallel heap iteration > parallel= use N threads for parallel heap iteration > > It's a bit inconsistent here in that it says , , and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has: > > Options: (options must be specified using the or = syntax) > -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false) > -gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1) > > The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or , or anything like that: > > "Number of parallel threads to use for heap inspection." > "0 (the default) means let the VM determine the number of threads to use. " > "1 means use one thread (disable parallelism). " > "For any other value the VM will try to use the specified number of threads, but might use fewer." > > I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given. Thanks @plummercj @sspitsyn for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From mli at openjdk.java.net Wed May 12 01:21:01 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 12 May 2021 01:21:01 GMT Subject: Integrated: JDK-8261034: improve jcmd GC.class_histogram to support parallel In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li wrote: > parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. This pull request has now been integrated. Changeset: 3c47cab6 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/3c47cab6db949b19cfd300139cbdbf81fb521e68 Stats: 98 lines in 4 files changed: 49 ins; 42 del; 7 mod 8261034: improve jcmd GC.class_histogram to support parallel Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From iklam at openjdk.java.net Wed May 12 04:43:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 12 May 2021 04:43:56 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Tue, 11 May 2021 03:24:23 GMT, Yumin Qi wrote: >> Hi, please review >> This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. >> The old PR description: >> ------------- old ------------ >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> ------------ new ------------- >> The new fix (incremental) >> 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. >> 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. >> 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. >> 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. >> >> Tests: tier1,tier2,tier3,tier4 >> local test on runtime/cds >> local test ParallelLambdaLoadTest.java in loops without crash. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused variables Hi Yumin, I applied your patch and ran ParallelLambdaLoadTest.java for about 400 iterations and I could no longer reproduce the crash in [JDK-8266765](https://bugs.openjdk.java.net/browse/JDK-8266765). As I mentioned in some of the individual comments, we need to properly handle the exceptions that can happen inside `MetaspaceShared::link_and_cleanup_shared_classes`. I think we should change these places: JVM_ENTRY_NO_ENV(void, JVM_BeforeHalt()) // Link all classes for dynamic CDS dumping before vm exit. if (DynamicDumpSharedSpaces) { - MetaspaceShared::link_and_cleanup_shared_classes(THREAD); + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); } ... void JavaThread::invoke_shutdown_hooks() { ... if (DynamicDumpSharedSpaces) { - MetaspaceShared::link_and_cleanup_shared_classes(this); + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); } And add a new function like this to catch the exception. If `link_and_cleanup_shared_classes` has thrown an exception, we should not dump the dynamic archive anymore. (We are already do that with the static archive). void DynamicArchive::prepare_for_dynamic_dumping_at_exit() { EXCEPTION_MARK; ResourceMark rm(THREAD); MetaspaceShared::link_and_cleanup_shared_classes(THREAD); if (HAS_PENDING_EXCEPTION) { log_error(cds)("ArchiveClassesAtExit has failed"); log_error(cds)("%s: %s", PENDING_EXCEPTION->klass()->external_name(), java_lang_String::as_utf8_string(java_lang_Throwable::message(PENDING_EXCEPTION))); // We cannot continue to dump the archive anymore. DynamicDumpSharedSpaces = false; CLEAR_PENDING_EXCEPTION; } } I would also suggest writing a new test case for the exception handling: run a program with something like `-Xmx64m -XX:ArchiveClassesAtExit`. The program should completely fill up the Java heap and exit. The dynamic archive should fail to dump due to OOM. src/hotspot/share/cds/dynamicArchive.cpp line 363: > 361: } > 362: > 363: void DynamicArchive::dump(TRAPS) { TRAPS is no longer needed since this function doesn't throw exceptions anymore. src/hotspot/share/cds/metaspaceShared.cpp line 629: > 627: java_lang_String::as_utf8_string(java_lang_Throwable::message(PENDING_EXCEPTION))); > 628: log_info(cds)("Regenerate lambdaform holder classes ...failed"); > 629: CLEAR_PENDING_EXCEPTION; // Exceptions are ignored. As we discussed in the [previous PR](https://github.com/openjdk/jdk/pull/3611#discussion_r623578292), we will get an exception here if we hit an OOM, or we have generated a bad classfile. In either case, the exception cannot be just ignored. It should be reported to the user and the dynamic dump should fail. I think we don't need this function anymore. Instead, the logging like `log_info(cds)("Regenerate lambdaform holder classes ...");` can be moved into `regenerate_holder_classes()`. The `HAS_PENDING_EXCEPTION` check should be removed. src/hotspot/share/cds/metaspaceShared.cpp line 638: > 636: // Collect all loaded ClassLoaderData. > 637: ResourceMark rm; > 638: regenerate_lambdaforminvokers_holders(THREAD); Should be `CHECK`. src/hotspot/share/prims/jvm.cpp line 3689: > 3687: Handle file_handle(THREAD, JNIHandles::resolve_non_null(archiveName)); > 3688: char* archive_name = java_lang_String::as_utf8_string(file_handle()); > 3689: MetaspaceShared::regenerate_lambdaforminvokers_holders(THREAD); The `THREAD` should be `CHECK`. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3953 From david.holmes at oracle.com Wed May 12 05:17:25 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 15:17:25 +1000 Subject: RFR: 8261395: C1 crash "cannot make java calls from the native compiler" [v2] In-Reply-To: <4IVcdgWmzH9AMSX8EKTJ3gjQMrJsehLQSlAQe8emOgk=.961d41eb-8244-4368-a5f6-b186bb8b3c45@github.com> References: <4IVcdgWmzH9AMSX8EKTJ3gjQMrJsehLQSlAQe8emOgk=.961d41eb-8244-4368-a5f6-b186bb8b3c45@github.com> Message-ID: <75a83bb7-9eab-d901-8492-c583e74ce368@oracle.com> Hi Coleen, On 12/05/2021 9:34 am, Coleen Phillimore wrote: > On Sun, 9 May 2021 22:10:24 GMT, David Holmes wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: >> >> - Update test per Coleen's comments: >> - need to add java.security.manager=allow just to be safe >> - simplify logic to read classfile from disk (ref ClassUnloadCommon.getClassData()) >> - Merge branch 'master' into 8261395-nestmember >> - Per Coleen: Reverse arguments order for has_nest_member so we can revert the introduction of "current". >> - Fix typo >> - Completely simpified the has_nest_member check to only use names. >> This avoids any possibility of class loading or executing any Java >> code and removes all possibility of exceptions in this part of the >> nestmate verification process. >> - Add test >> - Tweak logging message >> - 8261395: C1 crash "cannot make java calls from the native compiler" >> - First cleanup: when we have a resolved klass we don't need to use klass_at but can use resolved_klass_at. Now exceptions are truly impossible. > > Looks good to me! > > test/hotspot/jtreg/runtime/Nestmates/protectionDomain/TestDifferentProtectionDomains.java line 80: > >> 78: try { >> 79: String clzFile = name.replaceAll("\\.", "/") + ".class"; >> 80: byte[] buff = getResourceAsStream(clzFile).readAllBytes(); > > There's a ClassUnloadCommon.getBytesForClass(name) that you could have called that does essentially what these two lines do. Maybe it's different enough to have this, so it's up to you to change it. It would be "wrong" to actually call that as it calls getResourceAsStream on a different ClassLoader. So I used the same logic but applied to the custom classloader instance. Thanks for the review. David ----- > ------------- > > Marked as reviewed by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3913 > From dholmes at openjdk.java.net Wed May 12 05:25:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 12 May 2021 05:25:22 GMT Subject: Integrated: 8261395: C1 crash "cannot make java calls from the native compiler" In-Reply-To: References: Message-ID: On Fri, 7 May 2021 05:26:41 GMT, David Holmes wrote: > If a nest host and a nest member are associated with different protection domains it can lead to execution of Java code (to validate the "new" protection domain) during a nestmate access check, if nest membership verification has not yet been performed. This will cause assertion or guarantee failures if executed by a JIT compiler thread during access checks. > > After much discussion and trying different solutions it was decided that the existing logic for nest membership validation unnecessarily tries to resolve constant-pool entries, when it suffices that the symbolic entry in the constant-pool has the same name as the class being checked. Given this check occurs after we have verified the nest host and the purported member are loaded by the same classloader and in the same runtime package, there can only be one class with the name of the member, and that is the member class. Hence resolution of the constant-pool entry serves no purpose but introduces the complexity of dealing with exceptions and avoiding Java code execution in compiler threads. > > @iklam contributed to an earlier version of the fix, and devised the initial testcase approach. > @coleenp also contributed to an earlier version of the fix. > > Thanks to both Coleen and Ioi for their insights, discussions and contributions. > > Testing: > - the new test > - tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: e828a939 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/e828a939a8155a3b4ab26811a405bb4e4b2b99e8 Stats: 226 lines in 4 files changed: 167 ins; 40 del; 19 mod 8261395: C1 crash "cannot make java calls from the native compiler" Co-authored-by: Ioi Lam Co-authored-by: Coleen Phillimore Reviewed-by: iklam, hseigel, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3913 From ddong at openjdk.java.net Wed May 12 05:31:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 12 May 2021 05:31:46 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/82d8cc6c..6a089b24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From rehn at openjdk.java.net Wed May 12 06:06:01 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 06:06:01 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:02:44 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn 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 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320: > >> 318: // JavaThreads will enter here with state _thread_in_native. >> 319: void JvmtiRawMonitor::raw_enter(Thread* self) { >> 320: // TODO Atomic::load on _owner field > > Why is this still a TODO? We have ~15 plain loads of _owner, I thought it would be nice to fix all at the same time and I did not want to clobber this with that also. I can do a follow-up and change them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Wed May 12 08:02:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 18:02:45 +1000 Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version In-Reply-To: References: Message-ID: <3b842b4f-18f5-0f58-b694-af038997cd76@oracle.com> Hi Calvin, On 12/05/2021 2:23 am, Calvin Cheung wrote: > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. I guess you missed the fact that I had changed the bug synopsis. Why not call this needs_old_verifier (or something like that) so that the exact meaning of this method is more clear? David > Tests: > - [x] tier1, 2 > > ------------- > > Commit messages: > - 8266822: Rename MetaspaceShared::is_old_class to has_old_class_version > > Changes: https://git.openjdk.java.net/jdk/pull/3983/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3983&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8266822 > Stats: 18 lines in 6 files changed: 4 ins; 0 del; 14 mod > Patch: https://git.openjdk.java.net/jdk/pull/3983.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3983/head:pull/3983 > > PR: https://git.openjdk.java.net/jdk/pull/3983 > From rehn at openjdk.java.net Wed May 12 08:04:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:04:55 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:08:30 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn 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 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42: > >> 40: // Important note: >> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM >> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint > > nit typo: s/e.g./e.g.,/ > nit typo: s/tranisition/transition/ Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43: > >> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM >> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint >> 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread, > > nit typo: s/VM thread/the VM thread/ Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > >> 50: // native for all operations. However we need to honor suspend request, not >> 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened >> 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe > > nit typo: s/suspend request/a suspend request/ > nit typo: s/Honoring suspened/Honoring a suspend request/ > nit typo: s/interrupt flag/the interrupt flag/ > (You'll probably want to reformat the changed lines a bit.) Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206: > >> 204: ~ThreadInVMfromNative() { >> 205: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); >> 206: _thread->set_thread_state(_thread_in_native); > > You're losing the assertion that we're transitioning from > `_thread_in_vm` to `_thread_in_native` here. Although, > the constructor did verify that we were in `_thread_in_native` > when we transitioned to `_thread_in_vm` so at least the > first half is still verified. > > Can you an assertion that we're in `_thread_in_vm` here? Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _om_exit; > > Instead of `_om_exit` maybe this should be more generic? > Perhaps `_om_op_done` or something like that? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 12 08:04:47 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:04:47 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixes for Dan ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/07ddf393..1c6448e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=01-02 Stats: 16 lines in 4 files changed: 3 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 12 08:08:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:08:55 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 19:08:46 GMT, Daniel D. Daugherty wrote: > Thumbs up on the over all logic. I only have minor nits and suggestions. Thank you! > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > >> 46: // The rules are: >> 47: // - We must never safepoint poll if raw monitor is owned. >> 48: // - We may safepoint poll before it is owned and after it have been released. > > nit typo: s/have been/has been/ Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: > >> 228: }; >> 229: >> 230: template > > When you mentioned doing this with templates, I was having > nightmares, but this one is not bad at all... :) > src/hotspot/share/runtime/objectMonitor.cpp line 313: > >> 311: if (current->is_suspended()) { >> 312: _om->_recursions = 0; >> 313: _om->_succ = NULL; > > Please add a comment after this line: > // Don't need a full fence after clearing successor here because of the call to exit(). Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From aph at openjdk.java.net Wed May 12 08:12:58 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 12 May 2021 08:12:58 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 16:05:24 GMT, Gerard Ziemski wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. >> >> We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > do not expose memory with exec priviledges unless explicitly asked for, fix the test intead to ask for exececutable memory as needed test/hotspot/gtest/runtime/test_os.cpp line 371: > 369: for (int stripe = 0; stripe < num_stripes; stripe++) { > 370: address q = p + (stripe * stripe_len); > 371: q = (address)os::attempt_reserve_memory_at((char*)q, stripe_len, true); A comment here would hurt no one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From rrich at openjdk.java.net Wed May 12 08:31:13 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 08:31:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rrich at openjdk.java.net Wed May 12 08:31:13 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 08:31:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:24 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: >> >>> 228: }; >>> 229: >>> 230: template >> >> When you mentioned doing this with templates, I was having >> nightmares, but this one is not bad at all... > > :) Any reason why you don't use a ThreadClosure instead of the template parameter. I reckon it cannot be performance since it is only used on the slow path. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From martin.doerr at sap.com Wed May 12 09:40:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 09:40:33 +0000 Subject: AW: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: Hi Thomas, your backport looks good to me. Best regards, Martin Von: jdk-updates-dev im Auftrag von Thomas St?fe Datum: Dienstag, 11. Mai 2021 um 06:46 An: jdk-updates-dev Cc: Hotspot dev runtime Betreff: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution Hi, May I please have a review for the downport of this patch. I would like to dowport it since it allows us to run gtests which test signal handling on Windows in 11u. This is a precondition for downporting "8257828 SafeFetch may crash if invoked in non-JavaThreads", which is also in work. JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff Original PR: https://git.openjdk.java.net/jdk/pull/1757 The original patch does not apply cleanly due to changes done in GTestWrapper.java in the wake of JEP 387. However, the delta is minimal (just one line). 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff Thank you! Thomas From thomas.stuefe at gmail.com Wed May 12 09:41:06 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 12 May 2021 11:41:06 +0200 Subject: [11u] RFR: 8185734: [Windows] Structured Exception Catcher missing around gtest execution In-Reply-To: References: Message-ID: Thanks a lot Martin. On Wed, May 12, 2021 at 11:40 AM Doerr, Martin wrote: > Hi Thomas, > > > > your backport looks good to me. > > > > Best regards, > > Martin > > > > > > *Von: *jdk-updates-dev im Auftrag > von Thomas St?fe > *Datum: *Dienstag, 11. Mai 2021 um 06:46 > *An: *jdk-updates-dev > *Cc: *Hotspot dev runtime > *Betreff: *[11u] RFR: 8185734: [Windows] Structured Exception Catcher > missing around gtest execution > > Hi, > > May I please have a review for the downport of this patch. I would like to > dowport it since it allows us to run gtests which test signal handling on > Windows in 11u. This is a precondition for downporting "8257828 SafeFetch > may crash if invoked in non-JavaThreads", which is also in work. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185734 > > Original patch: https://github.com/openjdk/jdk/commit/568dc29b.diff > Original PR: https://git.openjdk.java.net/jdk/pull/1757 > > The original patch does not apply cleanly due to changes done in > GTestWrapper.java in the wake of JEP 387. However, the delta is minimal > (just one line). > > 11u patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8185734-Windows-Structured-Exception-Catcher-missing-around-gtest-execution-11u.diff > > Thank you! > > Thomas > From vlivanov at openjdk.java.net Wed May 12 10:30:54 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 12 May 2021 10:30:54 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 05:31:46 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > comment The only way to trigger the problem without VM anonymous classes is to load the same class file by numerous class loaders and then construct `MethodHandle`s for some method in that class. It should be affected by the same problem with the hash function which uses only symbolic info. But I'm not sure how much numerous class loaders themselves will stretch the JVM. It can easily make the effects of `ResolvedMethodTable` negligible. Nevertheless, IMO it still makes sense to improve the hash function. unsigned int method_hash(const Method* method) { unsigned int hash = method->klass_name()->identity_hash(); hash = (hash * 31) ^ method->name()->identity_hash(); hash = (hash * 31) ^ method->signature()->identity_hash(); return hash; } There's the method address available (`Method*`) which can easily be mixed (as an additional component or as a replacement for any of existing components: method name/signature/holder holder name. For example, here's how `Symbol::identity_hash()` looks loke: class Symbol : public MetaspaceObj { ... unsigned identity_hash() const { unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); return ((unsigned)extract_hash(_hash_and_refcount) & 0xffff) | ((addr_bits ^ (length() << 8) ^ (( _body[0] << 8) | _body[1])) << 16); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From rehn at openjdk.java.net Wed May 12 10:56:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 10:56:15 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > Hi Robbin, > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > Thanks, Richard. Hi Richard, I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. Regarding ThreadClosure, we could use it, maybe that is preferable?! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From lzang at openjdk.java.net Wed May 12 11:10:37 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:10:37 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: References: Message-ID: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into pd - update copyright info - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=23 Stats: 841 lines in 5 files changed: 653 ins; 61 del; 127 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From ddong at openjdk.java.net Wed May 12 11:14:25 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 12 May 2021 11:14:25 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: update the implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/6a089b24..b20036a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Wed May 12 11:14:26 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 12 May 2021 11:14:26 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v4] In-Reply-To: References: Message-ID: <1U6lIvNE5pnyct-BA9CGwLjg5lYop5K1Y_IolYIyb-c=.687640c1-d523-4890-a189-33bbb2f76c66@github.com> On Wed, 12 May 2021 10:27:45 GMT, Vladimir Ivanov wrote: > The only way to trigger the problem without VM anonymous classes is to load the same class file by numerous class loaders and then construct `MethodHandle`s for some method in that class. It should be affected by the same problem with the hash function which uses only symbolic info. > > But I'm not sure how much numerous class loaders themselves will stretch the JVM. It can easily make the effects of `ResolvedMethodTable` negligible. > > Nevertheless, IMO it still makes sense to improve the hash function. > > ``` > unsigned int method_hash(const Method* method) { > unsigned int hash = method->klass_name()->identity_hash(); > hash = (hash * 31) ^ method->name()->identity_hash(); > hash = (hash * 31) ^ method->signature()->identity_hash(); > return hash; > } > ``` > > There's the method address available (`Method*`) which can easily be mixed (as an additional component or as a replacement for any of existing components: method name/signature/holder holder name. > > For example, here's how `Symbol::identity_hash()` looks loke: > > ``` > class Symbol : public MetaspaceObj { > ... > unsigned identity_hash() const { > unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); > return ((unsigned)extract_hash(_hash_and_refcount) & 0xffff) | > ((addr_bits ^ (length() << 8) ^ (( _body[0] << 8) | _body[1])) << 16); > } > ``` Hi Vladimir, Thanks for the comment. I have updated the implementation according to your suggestion. Thanks, Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From lzang at openjdk.java.net Wed May 12 11:14:55 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:14:55 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Dear Ralf(@schmelter-sap), I am not a reviewer, just want to state that this change looks good to me and also helpful. I have encountered an issue that happened 2 times among 100 times try when testing #2261. And after applied this change, it works normally for another 100 times test. Just FYI. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From lzang at openjdk.java.net Wed May 12 11:17:57 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:17:57 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> References: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> Message-ID: <_zH7zhSHNVXccz-n8ejwCp-_QIxvB5ICu_ieahs7ui4=.b732dbcb-aaaf-40c3-aa09-f3fe8fe720ef@github.com> On Wed, 12 May 2021 11:10:37 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f Dear Chris, Thanks a lot for reviewing. I did more stress tests recently and found an issue that seems could be fixed by #3628, I am still verifying it. Will update when I confirm it. Just FYI. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From rrich at openjdk.java.net Wed May 12 12:35:27 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 12:35:27 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <909VtnsgD4R5wqUITLJD9R_4jDxnhLSLL7DyBaah4Ug=.bff780ad-86d9-4d99-8a98-3314d806212d@github.com> On Wed, 12 May 2021 10:53:21 GMT, Robbin Ehn wrote: > > > > Hi Robbin, > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > Thanks, Richard. > > Hi Richard, > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. Yes, I'd think so too. > Regarding ThreadClosure, we could use it, maybe that is preferable?! Personally I'd prefer it but I'm fine with the current version too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Wed May 12 13:00:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 23:00:03 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <6d44b14a-875f-3658-970d-2604c0ebf1a5@oracle.com> On 12/05/2021 8:56 pm, Robbin Ehn wrote: > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > >> Hi Robbin, >> >> I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. >> >> Thanks, Richard. > > Hi Richard, > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. > > Regarding ThreadClosure, we could use it, maybe that is preferable?! Isn't a ThreadClosure for applying an operation to a set of threads? That is not what we are doing here. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From vlivanov at openjdk.java.net Wed May 12 13:42:10 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 12 May 2021 13:42:10 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses Message-ID: Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. Found 3 occurrences: - `Dependencies::find_finalizable_subclass()` - `reinitialize_vtable_of()` - `VM_RedefineClasses::increment_class_counter()` Testing: - [x] hs-tier1 - hs-tier4 ------------- Commit messages: - 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses Changes: https://git.openjdk.java.net/jdk/pull/3995/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3995&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266973 Stats: 55 lines in 7 files changed: 7 ins; 19 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/3995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3995/head:pull/3995 PR: https://git.openjdk.java.net/jdk/pull/3995 From gziemski at openjdk.java.net Wed May 12 14:45:42 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 12 May 2021 14:45:42 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v3] In-Reply-To: References: Message-ID: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. > > We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: use the existing executable flag to indicate whether we want to commit exec memory or not ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3865/files - new: https://git.openjdk.java.net/jdk/pull/3865/files/ad3467b4..63d33efc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3865&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3865&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3865/head:pull/3865 PR: https://git.openjdk.java.net/jdk/pull/3865 From gziemski at openjdk.java.net Wed May 12 14:49:12 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 12 May 2021 14:49:12 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:10:10 GMT, Andrew Haley wrote: >> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: >> >> do not expose memory with exec priviledges unless explicitly asked for, fix the test intead to ask for exececutable memory as needed > > test/hotspot/gtest/runtime/test_os.cpp line 371: > >> 369: for (int stripe = 0; stripe < num_stripes; stripe++) { >> 370: address q = p + (stripe * stripe_len); >> 371: q = (address)os::attempt_reserve_memory_at((char*)q, stripe_len, true); > > A comment here would hurt no one. I used the existing "executable" flag here, which already had a comment explaining it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From kvn at openjdk.java.net Wed May 12 15:02:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 12 May 2021 15:02:55 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses In-Reply-To: References: Message-ID: <8Q7v434yMq1-JtD6TcZdSTjv-XskLWX5VIFrdsoaB7I=.677070dc-9f80-4587-a4ac-362ec82e180f@github.com> On Wed, 12 May 2021 13:30:09 GMT, Vladimir Ivanov wrote: > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 Seems good. I don't see link to testing in RFE. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3995 From minqi at openjdk.java.net Wed May 12 15:06:56 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 12 May 2021 15:06:56 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Wed, 12 May 2021 04:40:30 GMT, Ioi Lam wrote: > Hi Yumin, > > I applied your patch and ran ParallelLambdaLoadTest.java for about 400 iterations and I could no longer reproduce the crash in [JDK-8266765](https://bugs.openjdk.java.net/browse/JDK-8266765). > > As I mentioned in some of the individual comments, we need to properly handle the exceptions that can happen inside `MetaspaceShared::link_and_cleanup_shared_classes`. I think we should change these places: > > ``` > JVM_ENTRY_NO_ENV(void, JVM_BeforeHalt()) > // Link all classes for dynamic CDS dumping before vm exit. > if (DynamicDumpSharedSpaces) { > - MetaspaceShared::link_and_cleanup_shared_classes(THREAD); > + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); > } > ... > > void JavaThread::invoke_shutdown_hooks() { > ... > if (DynamicDumpSharedSpaces) { > - MetaspaceShared::link_and_cleanup_shared_classes(this); > + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); > } > ``` > > And add a new function like this to catch the exception. If `link_and_cleanup_shared_classes` has thrown an exception, we should not dump the dynamic archive anymore. (We are already do that with the static archive). > > ``` > void DynamicArchive::prepare_for_dynamic_dumping_at_exit() { > EXCEPTION_MARK; > ResourceMark rm(THREAD); > MetaspaceShared::link_and_cleanup_shared_classes(THREAD); > if (HAS_PENDING_EXCEPTION) { > log_error(cds)("ArchiveClassesAtExit has failed"); > log_error(cds)("%s: %s", PENDING_EXCEPTION->klass()->external_name(), > java_lang_String::as_utf8_string(java_lang_Throwable::message(PENDING_EXCEPTION))); > // We cannot continue to dump the archive anymore. > DynamicDumpSharedSpaces = false; > CLEAR_PENDING_EXCEPTION; > } > } The function name should be prepare_for_dynamic_dumping since it is called when jcmd does dynamic dumping which does not exit after dumping archive. > > I would also suggest writing a new test case for the exception handling: run a program with something like `-Xmx64m -XX:ArchiveClassesAtExit`. The program should completely fill up the Java heap and exit. The dynamic archive should fail to dump due to OOM. Sure will add test for this. > src/hotspot/share/cds/dynamicArchive.cpp line 363: > >> 361: } >> 362: >> 363: void DynamicArchive::dump(TRAPS) { > > TRAPS is no longer needed since this function doesn't throw exceptions anymore. Will revert to original version. > src/hotspot/share/cds/metaspaceShared.cpp line 638: > >> 636: // Collect all loaded ClassLoaderData. >> 637: ResourceMark rm; >> 638: regenerate_lambdaforminvokers_holders(THREAD); > > Should be `CHECK`. will remove the call from this spot, move to its original spot to call regeneration. > src/hotspot/share/prims/jvm.cpp line 3689: > >> 3687: Handle file_handle(THREAD, JNIHandles::resolve_non_null(archiveName)); >> 3688: char* archive_name = java_lang_String::as_utf8_string(file_handle()); >> 3689: MetaspaceShared::regenerate_lambdaforminvokers_holders(THREAD); > > The `THREAD` should be `CHECK`. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From vlivanov at openjdk.java.net Wed May 12 15:11:25 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 12 May 2021 15:11:25 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses In-Reply-To: References: Message-ID: <2tu459STWm4pe5NkxcG6atYlSqqUtOihj9BGf0Z3DLU=.3313f2de-5926-456a-8b91-f3873fbf38ae@github.com> On Wed, 12 May 2021 13:30:09 GMT, Vladimir Ivanov wrote: > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 Thanks for the review, Vladimir. > I don't see link to testing in RFE. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3995 From gziemski at openjdk.java.net Wed May 12 15:13:53 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 12 May 2021 15:13:53 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 14:45:42 GMT, Gerard Ziemski wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. >> >> We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > use the existing executable flag to indicate whether we want to commit exec memory or not Talking about "exec" permission of the memory in `os::pd_commit_memory` got me thinking about the permissions we currently set on it, which is: `int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE` I'm sure there must be a reason, that I don't know, but why do we need it to be of "PROT_READ"? Java2Demo, for example, seems to run fine without the "read" permission on it, i.e.: `int prot = exec ? PROT_WRITE|PROT_EXEC : PROT_WRITE;` ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From rrich at openjdk.java.net Wed May 12 15:31:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 15:31:11 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Hi Ralf, your change looks good to me. Thanks for fixing, Richard. src/hotspot/share/services/heapDumperCompression.cpp line 262: > 260: } > 261: > 262: void CompressionBackend::thread_loop() { You could simplify `CompressionBackend::thread_loop()` further: void CompressionBackend::thread_loop() { { MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); _nr_of_threads++; } WriteWork* work = get_work(); while (work != NULL) { do_compress(work); finish_work(work); work = get_work(); } MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); _nr_of_threads--; assert(_nr_of_threads >= 0, "Too many threads finished"); ml.notify_all(); } ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From rrich at openjdk.java.net Wed May 12 15:31:12 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 15:31:12 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> On Wed, 12 May 2021 14:37:14 GMT, Richard Reingruber wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > src/hotspot/share/services/heapDumperCompression.cpp line 262: > >> 260: } >> 261: >> 262: void CompressionBackend::thread_loop() { > > You could simplify `CompressionBackend::thread_loop()` further: > > > void CompressionBackend::thread_loop() { > { > MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); > _nr_of_threads++; > } > > WriteWork* work = get_work(); > while (work != NULL) { > do_compress(work); > finish_work(work); > work = get_work(); > } > > MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); > _nr_of_threads--; > assert(_nr_of_threads >= 0, "Too many threads finished"); > ml.notify_all(); > } BTW: why is `ml.notify_all()` in line 275 needed at all? ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From iklam at openjdk.java.net Wed May 12 15:44:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 12 May 2021 15:44:59 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Wed, 12 May 2021 15:01:30 GMT, Yumin Qi wrote: > The function name should be prepare_for_dynamic_dumping since it is called when jcmd does dynamic dumping which does not exit after dumping archive. This function should not be called by the jcmd code. This function catches exceptions that happens inside `MetaspaceShared::link_and_cleanup_shared_classes()`, but in your existing code, jcmd doesn't call `MetaspaceShared::link_and_cleanup_shared_classes()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From minqi at openjdk.java.net Wed May 12 16:08:55 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 12 May 2021 16:08:55 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Wed, 12 May 2021 15:41:36 GMT, Ioi Lam wrote: > > The function name should be prepare_for_dynamic_dumping since it is called when jcmd does dynamic dumping which does not exit after dumping archive. > > This function should not be called by the jcmd code. This function catches exceptions that happens inside `MetaspaceShared::link_and_cleanup_shared_classes()`, but in your existing code, jcmd doesn't call `MetaspaceShared::link_and_cleanup_shared_classes()`. Realized that, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From coleenp at openjdk.java.net Wed May 12 16:22:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 12 May 2021 16:22:21 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 11:14:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > update the implementation src/hotspot/share/prims/resolvedMethodTable.cpp line 59: > 57: hash = (hash * 31) ^ method->name()->identity_hash(); > 58: hash = (hash * 31) ^ method->signature()->identity_hash(); > 59: return hash ^ (unsigned)((uintptr_t)method >> (LogMinObjAlignmentInBytes + 3)); I agree with Vladimir that it makes sense to improve the hashing function of the ResolvedMethodTable for the special case of names matching. You have to use the ClassLoaderData though, not the Method* because the reason for the table is to replace Method* in the case of redefinition. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Wed May 12 17:34:26 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 12 May 2021 17:34:26 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v5] In-Reply-To: References: Message-ID: <7HB3pamSSYkub-EbBwgpkP_WWO_yn1HggGT8KkGhIbc=.3f2288e7-fa0a-4fc9-83c9-a6155c5603ee@github.com> On Wed, 12 May 2021 16:19:09 GMT, Coleen Phillimore wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> update the implementation > > src/hotspot/share/prims/resolvedMethodTable.cpp line 59: > >> 57: hash = (hash * 31) ^ method->name()->identity_hash(); >> 58: hash = (hash * 31) ^ method->signature()->identity_hash(); >> 59: return hash ^ (unsigned)((uintptr_t)method >> (LogMinObjAlignmentInBytes + 3)); > > I agree with Vladimir that it makes sense to improve the hashing function of the ResolvedMethodTable for the special case of names matching. You have to use the ClassLoaderData though, not the Method* because the reason for the table is to replace Method* in the case of redefinition. fixed, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Wed May 12 17:34:25 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 12 May 2021 17:34:25 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: use ClassLoaderData* as factor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/b20036a3..c7c54ae2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From rschmelter at openjdk.java.net Wed May 12 17:55:57 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Wed, 12 May 2021 17:55:57 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> Message-ID: On Wed, 12 May 2021 15:22:52 GMT, Richard Reingruber wrote: >> src/hotspot/share/services/heapDumperCompression.cpp line 262: >> >>> 260: } >>> 261: >>> 262: void CompressionBackend::thread_loop() { >> >> You could simplify `CompressionBackend::thread_loop()` further: >> >> >> void CompressionBackend::thread_loop() { >> { >> MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); >> _nr_of_threads++; >> } >> >> WriteWork* work = get_work(); >> while (work != NULL) { >> do_compress(work); >> finish_work(work); >> work = get_work(); >> } >> >> MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); >> _nr_of_threads--; >> assert(_nr_of_threads >= 0, "Too many threads finished"); >> ml.notify_all(); >> } > > BTW: why is `ml.notify_all()` in line 275 needed at all? Hi, thanks for the review Lin and Richard. The notify_all() is indeed not needed anymore. It was originally needed when the worker threads were newly created threads and we had to wait for them to finish at the end of the dump operation. But since we now use the GC work gang, this can be removed. I will update the PR with your suggestions. Best regards, Ralf ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From coleenp at openjdk.java.net Wed May 12 18:53:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 12 May 2021 18:53:02 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses In-Reply-To: References: Message-ID: <1n4hp0FnDEtYEhg3p-RIW5NlkXoJoFej5tGBgIAVCMc=.35c4d7ab-0d66-497c-90d9-54c08c35abd1@github.com> On Wed, 12 May 2021 13:30:09 GMT, Vladimir Ivanov wrote: > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 This looks really good. I wonder if you can now make subklass() and next_sibling() functions private to Klass with it having ClassHierarchyIterator as a friend. If not, I still approve. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3995 From cjplummer at openjdk.java.net Wed May 12 22:44:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 12 May 2021 22:44:59 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> References: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> Message-ID: On Wed, 12 May 2021 11:10:37 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Thu May 13 01:17:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 01:17:55 GMT Subject: RFR: 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh In-Reply-To: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> References: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> Message-ID: On Tue, 11 May 2021 23:32:24 GMT, David Holmes wrote: > Please see the bug report for detailed description of the issue. The simple fix for the test is to disable inlining of the lock() method (something which I think the existing MaxInlineLevel flags were trying to achieve but didn't). > > Testing: > - before fix I ran the test 50x on linux-x64, macos-x64 and macos-aarch64 product and fastdebug -> 300 failures > - after: 300 successes > - I also ran the fixed version 50x across all platforms using the test flags from tiers 1 through 8 (total of 1408 test runs) with zero failures or crashes. > > Thanks, > David Thanks Dan. I'll push this now. I also ran the fixed version of the test, 50x across all platforms using the test flags from tiers 1 through 8 (total of 1408 test runs) with zero failures or crashes. So confidence is high. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3989 From dholmes at openjdk.java.net Thu May 13 01:17:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 01:17:55 GMT Subject: Integrated: 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh In-Reply-To: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> References: <19ao9WfawinoVImhpskAsBpPxlPs65Rw6-0JIOLqT1U=.d53de989-6706-45ce-9000-49f3e9ab38b1@github.com> Message-ID: On Tue, 11 May 2021 23:32:24 GMT, David Holmes wrote: > Please see the bug report for detailed description of the issue. The simple fix for the test is to disable inlining of the lock() method (something which I think the existing MaxInlineLevel flags were trying to achieve but didn't). > > Testing: > - before fix I ran the test 50x on linux-x64, macos-x64 and macos-aarch64 product and fastdebug -> 300 failures > - after: 300 successes > - I also ran the fixed version 50x across all platforms using the test flags from tiers 1 through 8 (total of 1408 test runs) with zero failures or crashes. > > Thanks, > David This pull request has now been integrated. Changeset: d215743a Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/d215743a91555c4edabd116b1899765d5a283dc7 Stats: 6 lines in 2 files changed: 4 ins; 1 del; 1 mod 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3989 From dholmes at openjdk.java.net Thu May 13 01:45:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 01:45:09 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v5] In-Reply-To: References: Message-ID: <8aRBe9Qaf0ztWgSoA_akBA-vlWPf2Rn2M7AiAVEYres=.3c5764ff-0521-489f-afb5-3427044b3a4a@github.com> On Tue, 11 May 2021 23:31:20 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Make methods strict on IA32. Sub-task "JDK-8266950: Remove vestigial support for non-strict floating-point execution" is being used to change the hotspot code so that `is_strict` is replaced by true and the resulting code modified accordingly. This PR will focus only on the handling of the ACC_STRICT flag during classfile parsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From dholmes at openjdk.java.net Thu May 13 01:59:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 01:59:02 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler [v2] In-Reply-To: References: Message-ID: <9iur1L-sdHotGlihX7uAM2pMxfay-dhC529MCOHNHqQ=.c86cf870-81fb-4ba1-b9fa-571e0930fea6@github.com> On Tue, 11 May 2021 12:27:24 GMT, Hamlin Li wrote: >> This is trivial change to remove dead code in low memory detector. > > Hamlin Li 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 remote-tracking branch 'refs/remotes/origin/remove-LowMemoryDetectorDisabler' into remove-LowMemoryDetectorDisabler > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - remove more dead code. > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - JDK-8266795: remove dead code LowMemoryDetectorDisabler Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3964 From dholmes at openjdk.java.net Thu May 13 03:54:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 03:54:10 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report Message-ID: A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. Tested tiers 1-3 for good measure. Thanks, David ------------- Commit messages: - 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report Changes: https://git.openjdk.java.net/jdk/pull/4006/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4006&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266404 Stats: 36 lines in 4 files changed: 27 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4006.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4006/head:pull/4006 PR: https://git.openjdk.java.net/jdk/pull/4006 From dholmes at openjdk.java.net Thu May 13 05:12:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 05:12:56 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio Hi Patricio, Apologies for missing your original explanation about the unsafe-access checking. The changes seem fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3919 From stuefe at openjdk.java.net Thu May 13 05:51:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 13 May 2021 05:51:57 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report In-Reply-To: References: Message-ID: On Thu, 13 May 2021 02:14:43 GMT, David Holmes wrote: > A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. > > VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. > > Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. > > Tested tiers 1-3 for good measure. > > Thanks, > David Hi David, mostly fine, minor nits. Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps. Cheers, Thomas src/hotspot/share/utilities/debug.cpp line 294: > 292: void report_fatal_impl(VMErrorType error_type, const char* file, int line, > 293: const char* detail_fmt, va_list detail_args) > 294: ATTRIBUTE_PRINTF(4,0); Can prototype and implementation be merged while retaining the attrib marker? src/hotspot/share/utilities/debug.cpp line 298: > 296: // Definition > 297: void report_fatal_impl(VMErrorType error_type, const char* file, int line, > 298: const char* detail_fmt, va_list detail_args) { Can this function be static? Any reason to expose it? src/hotspot/share/utilities/debug.hpp line 154: > 152: OOM_MMAP_ERROR = 0xe0000002, > 153: OOM_MPROTECT_ERROR = 0xe0000003, > 154: OOM_JAVA_HEAP_FATAL = 0xe000004 Add one more zero? To keep it in line with the other errors? src/hotspot/share/utilities/debug.hpp line 168: > 166: int status, const char* detail); > 167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4); > 168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5); See above, can we not expose this? ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4006 From dholmes at openjdk.java.net Thu May 13 06:07:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 06:07:00 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, Sorry for the delay in getting through this. Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. Thanks, David src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > 46: // The rules are: > 47: // - We must never safepoint poll if raw monitor is owned. > 48: // - We may safepoint poll before it is owned and after it has been released. I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96: > 94: protected: > 95: JvmtiRawMonitor* _rm; > 96: bool _rm_exit; If this signifies the monitor exited then please name it `_rm_exited`. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207: > 205: assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state"); > 206: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); > 207: _thread->set_thread_state(_thread_in_native); After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: > 275: class ThreadBlockInVM { > 276: InFlightMutexRelease _ifmr; > 277: ThreadBlockInVMPreprocess _tbivmpp; Why delegate to the TBIVMPP instead of extending it? src/hotspot/share/runtime/objectMonitor.cpp line 435: > 433: EnterI(current); > 434: } > 435: if (!eos.om_op_done()) { I find this API too generic. I'd much rather see: if (!eos.exited()) { assert ... break; } src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _om_op_done; Please rename to _exited - we know what the "op" is so no need to use generic terminology. src/hotspot/share/runtime/objectMonitor.hpp line 313: > 311: ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {} > 312: void operator()(JavaThread* current); > 313: bool om_op_done() { return _om_op_done; } please rename to exited() src/hotspot/share/runtime/objectMonitor.hpp line 315: > 313: bool om_op_done() { return _om_op_done; } > 314: }; > 315: class ClearSuccOnSuspend : public ExitOnSuspend { I don't see why there is any relationship between these two. You don't clear-succ and exit. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From yyang at openjdk.java.net Thu May 13 07:15:04 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 13 May 2021 07:15:04 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable Message-ID: While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. ------------- Commit messages: - use kvtable directly Changes: https://git.openjdk.java.net/jdk/pull/4007/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4007&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267089 Stats: 9 lines in 2 files changed: 3 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4007/head:pull/4007 PR: https://git.openjdk.java.net/jdk/pull/4007 From david.holmes at oracle.com Thu May 13 08:03:47 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 May 2021 18:03:47 +1000 Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report In-Reply-To: References: Message-ID: <41608409-6444-da49-159d-438e09462dbe@oracle.com> Hi Thomas, Thanks for looking at this. On 13/05/2021 3:51 pm, Thomas Stuefe wrote: > On Thu, 13 May 2021 02:14:43 GMT, David Holmes wrote: > >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > Hi David, > > mostly fine, minor nits. > > Side note, I really would like to clean up this coding a bit. I have attempted to so so multiple times, but the patches ballooned. I may try again, maybe in tiny baby steps. > > Cheers, Thomas > > src/hotspot/share/utilities/debug.cpp line 294: > >> 292: void report_fatal_impl(VMErrorType error_type, const char* file, int line, >> 293: const char* detail_fmt, va_list detail_args) >> 294: ATTRIBUTE_PRINTF(4,0); > > Can prototype and implementation be merged while retaining the attrib marker? Unfortunately no, that is why they are both present and commented. > src/hotspot/share/utilities/debug.cpp line 298: > >> 296: // Definition >> 297: void report_fatal_impl(VMErrorType error_type, const char* file, int line, >> 298: const char* detail_fmt, va_list detail_args) { > > Can this function be static? Any reason to expose it? No reason to expose. Changed to static. > src/hotspot/share/utilities/debug.hpp line 154: > >> 152: OOM_MMAP_ERROR = 0xe0000002, >> 153: OOM_MPROTECT_ERROR = 0xe0000003, >> 154: OOM_JAVA_HEAP_FATAL = 0xe000004 > > Add one more zero? To keep it in line with the other errors? Ooops! Well spotted. I've no idea why these are expressed this way though and not just 0, 1, 2, 3, 4. > src/hotspot/share/utilities/debug.hpp line 168: > >> 166: int status, const char* detail); >> 167: void report_fatal(const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4); >> 168: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5); > > See above, can we not expose this? ?? These are the ones that are meant to be exposed. We hide behind the fatal() macro for the first case but these are the exported API. Thanks, David > ------------- > > Changes requested by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4006 > From dholmes at openjdk.java.net Thu May 13 08:06:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 08:06:24 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: References: Message-ID: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> > A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. > > VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. > > Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. > > Tested tiers 1-3 for good measure. > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Review comments from Thomas ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4006/files - new: https://git.openjdk.java.net/jdk/pull/4006/files/f83eda4c..147b5cf1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4006&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4006&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4006.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4006/head:pull/4006 PR: https://git.openjdk.java.net/jdk/pull/4006 From dholmes at openjdk.java.net Thu May 13 08:14:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 08:14:55 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Drop exit_delta and the VMTestbase style of exiting on test failure. Hi Dan, Seems fine. Thanks for the updates. The proof of a test is in its execution :) David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3478 From vlivanov at openjdk.java.net Thu May 13 09:36:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 13 May 2021 09:36:40 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses [v2] In-Reply-To: References: Message-ID: > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JFR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3995/files - new: https://git.openjdk.java.net/jdk/pull/3995/files/cb586871..54a4bddd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3995&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3995&range=00-01 Stats: 46 lines in 2 files changed: 1 ins; 35 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3995/head:pull/3995 PR: https://git.openjdk.java.net/jdk/pull/3995 From vlivanov at openjdk.java.net Thu May 13 09:39:58 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 13 May 2021 09:39:58 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses [v2] In-Reply-To: <1n4hp0FnDEtYEhg3p-RIW5NlkXoJoFej5tGBgIAVCMc=.35c4d7ab-0d66-497c-90d9-54c08c35abd1@github.com> References: <1n4hp0FnDEtYEhg3p-RIW5NlkXoJoFej5tGBgIAVCMc=.35c4d7ab-0d66-497c-90d9-54c08c35abd1@github.com> Message-ID: On Wed, 12 May 2021 18:49:41 GMT, Coleen Phillimore wrote: > I wonder if you can now make subklass() and next_sibling() functions private to Klass with it having ClassHierarchyIterator as a friend. There are some usages of `subklass()`/`next_sibling()` which don't benefit much from migration to `ClassHierarchyIterator` (e.g., `Dependencies::check_leaf_type()` and `ciInstanceKlass::dump_replay_data()`). I decided to leave them intact. Nevertheless, I spotted 2 more occurrences (in JFR code) that benefit from migration to `ClassHierarchyIterator`. (Passed `hs-tier5-rt` - `hs-tier7-rt` testing.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3995 From thomas.stuefe at gmail.com Thu May 13 10:47:22 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 13 May 2021 12:47:22 +0200 Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report In-Reply-To: <41608409-6444-da49-159d-438e09462dbe@oracle.com> References: <41608409-6444-da49-159d-438e09462dbe@oracle.com> Message-ID: Hi David, On Thu, May 13, 2021 at 10:04 AM David Holmes wrote: > Hi Thomas, > > Thanks for looking at this. > > On 13/05/2021 3:51 pm, Thomas Stuefe wrote: > > On Thu, 13 May 2021 02:14:43 GMT, David Holmes > wrote: > > > >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate > we've requested a Java OOM error to be fatal. A new overload of > report_fatal is provided to allow this to be passed through. > >> > >> VMError has an existing notion of "should_report_bug" but that > encompasses more than just printing the bug submission URL, so I added a > new specific check for that. > >> > >> Checked hs_err files before and after with the fix, from the > CrashOnOutOfMemoryError test. > >> > >> Tested tiers 1-3 for good measure. > >> > >> Thanks, > >> David > > > > Hi David, > > > > mostly fine, minor nits. > > > > Side note, I really would like to clean up this coding a bit. I have > attempted to so so multiple times, but the patches ballooned. I may try > again, maybe in tiny baby steps. > > > > Cheers, Thomas > > > > src/hotspot/share/utilities/debug.cpp line 294: > > > >> 292: void report_fatal_impl(VMErrorType error_type, const char* file, > int line, > >> 293: const char* detail_fmt, va_list detail_args) > >> 294: ATTRIBUTE_PRINTF(4,0); > > > > Can prototype and implementation be merged while retaining the attrib > marker? > > Unfortunately no, that is why they are both present and commented. > > > src/hotspot/share/utilities/debug.cpp line 298: > > > >> 296: // Definition > >> 297: void report_fatal_impl(VMErrorType error_type, const char* file, > int line, > >> 298: const char* detail_fmt, va_list > detail_args) { > > > > Can this function be static? Any reason to expose it? > > No reason to expose. Changed to static. > > > src/hotspot/share/utilities/debug.hpp line 154: > > > >> 152: OOM_MMAP_ERROR = 0xe0000002, > >> 153: OOM_MPROTECT_ERROR = 0xe0000003, > >> 154: OOM_JAVA_HEAP_FATAL = 0xe000004 > > > > Add one more zero? To keep it in line with the other errors? > > Ooops! Well spotted. I've no idea why these are expressed this way > though and not just 0, 1, 2, 3, 4. > > This enum, signal numbers (posix) and windows SEH codes are mashed together in VMError::_id. I guess this is some effort to make sure value ranges for these three semantically different things don't intersect. I don't like this design though. I would like to keep these as two separate things: at the highest lvl, differentiate between internal fatal errors and crashes. For each type keep detail info: For crashes, signal number+context+siginfo. For asserts, error type and maybe context. > > src/hotspot/share/utilities/debug.hpp line 168: > > > >> 166: int status, const char* detail); > >> 167: void report_fatal(const char* file, int line, const char* > detail_fmt, ...) ATTRIBUTE_PRINTF(3, 4); > >> 168: void report_fatal(VMErrorType error_type, const char* file, int > line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5); > > > > See above, can we not expose this? > > ?? These are the ones that are meant to be exposed. We hide behind the > fatal() macro for the first case but these are the exported API. > > Yes, but atm the sole user of this api lives in debug.cpp. Otherwise this API is only exposed via the specialized report_java_out_of_memory(). Never mind though, it is not that important. > Thanks, > David > > Patch looks good to me. Cheers, Thomas > > ------------- > > > > Changes requested by stuefe (Reviewer). > > > > PR: https://git.openjdk.java.net/jdk/pull/4006 > > > From stuefe at openjdk.java.net Thu May 13 10:50:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 13 May 2021 10:50:55 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: On Thu, 13 May 2021 08:06:24 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from Thomas All good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4006 From vlivanov at openjdk.java.net Thu May 13 11:51:12 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 13 May 2021 11:51:12 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests Message-ID: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. In particular: - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; - pass `TestBuilder` as a parameter and initiate test execution from executor; - switch max class file version tested from 52 to 61 (`V17`); - minor changes (cleanups, new test cases) Testing: - [x] vmTestbase/vm/runtime/defmeth/ - [x] hs-tier5-rt - hs-tier8-rt ------------- Commit messages: - Cleanup - Remove scenarios - FIXME removal - Fixes - TestBuilder as a parameter Changes: https://git.openjdk.java.net/jdk/pull/4008/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267095 Stats: 17502 lines in 391 files changed: 323 ins; 16888 del; 291 mod Patch: https://git.openjdk.java.net/jdk/pull/4008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4008/head:pull/4008 PR: https://git.openjdk.java.net/jdk/pull/4008 From dholmes at openjdk.java.net Thu May 13 12:46:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 12:46:29 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution Message-ID: As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. Testing: tiers 1-3 Thanks, David ------------- Commit messages: - Removed divDPR_reg_round as it has a false predicate and so is now unused - Revert classFileParser changes as they will be handled by JDK-8266530 - 8266530: HotSpot changes for JEP 306 Changes: https://git.openjdk.java.net/jdk/pull/3991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266950 Stats: 203 lines in 27 files changed: 4 ins; 153 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From pchilanomate at openjdk.java.net Thu May 13 14:52:29 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 13 May 2021 14:52:29 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition [v2] In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: <-6rkUNgZrS4Px3koGAH2eD_XElnU7C0OxOP3iTtR9Uc=.d53595ac-e019-4602-8e21-13ab6556dbb8@github.com> > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio Patricio Chilano Mateo 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 8265934 - v1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3919/files - new: https://git.openjdk.java.net/jdk/pull/3919/files/b538f995..78ec1068 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3919&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3919&range=00-01 Stats: 39077 lines in 930 files changed: 19359 ins; 10629 del; 9089 mod Patch: https://git.openjdk.java.net/jdk/pull/3919.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3919/head:pull/3919 PR: https://git.openjdk.java.net/jdk/pull/3919 From ddong at openjdk.java.net Thu May 13 14:55:58 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 13 May 2021 14:55:58 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:34:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > use ClassLoaderData* as factor test with this improvement: Passed: runtime/MemberName/ResolvedMethodTableHash.java build: 0.587 seconds compile: 0.585 seconds main: 3.495 seconds Test results: passed: 1 test without this improvement: Passed: runtime/MemberName/ResolvedMethodTableHash.java build: 0.581 seconds compile: 0.579 seconds main: 10.896 seconds Test results: passed: 1 ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From pchilanomate at openjdk.java.net Thu May 13 14:56:05 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 13 May 2021 14:56:05 GMT Subject: RFR: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition [v2] In-Reply-To: <-6rkUNgZrS4Px3koGAH2eD_XElnU7C0OxOP3iTtR9Uc=.d53595ac-e019-4602-8e21-13ab6556dbb8@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> <-6rkUNgZrS4Px3koGAH2eD_XElnU7C0OxOP3iTtR9Uc=.d53595ac-e019-4602-8e21-13ab6556dbb8@github.com> Message-ID: On Thu, 13 May 2021 14:52:29 GMT, Patricio Chilano Mateo wrote: >> Hi, >> >> Please review the following patch which contains the following cleanups: >> >> - Move _suspend_flags from Thread class to JavaThread >> >> - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). >> >> - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. >> >> - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. >> >> Tested in mach5 tiers 1-6. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo 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 8265934 > - v1 Hi David, > Hi Patricio, > > Apologies for missing your original explanation about the unsafe-access checking. > > The changes seem fine. Thanks for the review! Patricio > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From dcubed at openjdk.java.net Thu May 13 15:40:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 13 May 2021 15:40:55 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 08:12:22 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop exit_delta and the VMTestbase style of exiting on test failure. > > Hi Dan, > > Seems fine. Thanks for the updates. > > The proof of a test is in its execution :) > > David @dholmes-ora - Thanks for the re-review. My Mach5 Tier[1-7] testing for an earlier version of the test is documented in the bug report. @plummercj - Are you still planning to review this new test? ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From stuefe at openjdk.java.net Thu May 13 15:49:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 13 May 2021 15:49:08 GMT Subject: RFR: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed Message-ID: My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. Tested manually with various time zones. ------------- Commit messages: - fix test Changes: https://git.openjdk.java.net/jdk/pull/4013/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4013&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266942 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4013/head:pull/4013 PR: https://git.openjdk.java.net/jdk/pull/4013 From akozlov at openjdk.java.net Thu May 13 16:12:03 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 13 May 2021 16:12:03 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint In-Reply-To: <0fYZ1LpFwjF4ULZqdBaJVyPsifjVSyi55PpRbV3Kcp4=.30261f9b-4431-4efe-b6e7-fd595f44f3d8@github.com> References: <0fYZ1LpFwjF4ULZqdBaJVyPsifjVSyi55PpRbV3Kcp4=.30261f9b-4431-4efe-b6e7-fd595f44f3d8@github.com> Message-ID: On Mon, 10 May 2021 05:23:29 GMT, David Holmes wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > src/hotspot/os/bsd/globals_bsd.hpp line 39: > >> 37: constraint) \ >> 38: \ >> 39: AARCH64_ONLY(develop(bool, WXCheckAtSafepoint, false, \ > > Why not enable always as this is a develop build? Do we even need to manage this on a flag? > > Also not really "safepoint" as the check also applies to handshakes. Even in debug builds the check may be too assertive. This check exposes 22 failures in tier1 in jfr, gc, compiler, serviceability, and foreign (hope to be fixed soon), and they look like actual possible issues. So I suggest to have the option but keep it disabled. But if one meets with something similar to JDK-8265292, then it will be possible to reproduce otherwise intermittent crash. ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From akozlov at openjdk.java.net Thu May 13 16:18:19 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 13 May 2021 16:18:19 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). > > This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. > > I still owe a complete W^X approach description. Hope this patch does not depend much on that. Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Change option and method name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3920/files - new: https://git.openjdk.java.net/jdk/pull/3920/files/f979fd08..589db510 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3920&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3920&range=00-01 Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3920.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3920/head:pull/3920 PR: https://git.openjdk.java.net/jdk/pull/3920 From akozlov at openjdk.java.net Thu May 13 16:34:54 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 13 May 2021 16:34:54 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:18:19 GMT, Anton Kozlov wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Change option and method name Thanks! I've changed the option and the method name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From mr at openjdk.java.net Thu May 13 17:24:10 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 13 May 2021 17:24:10 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Message-ID: Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on {linux,macos,windows}-x64 and {linux,macos}-aarch64. ------------- Commit messages: - 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Changes: https://git.openjdk.java.net/jdk/pull/4015/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266851 Stats: 2811 lines in 16 files changed: 0 ins; 2782 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015 From hseigel at openjdk.java.net Thu May 13 17:41:17 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 17:41:17 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals In-Reply-To: References: Message-ID: On Thu, 13 May 2021 17:14:36 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. src/hotspot/share/runtime/arguments.cpp line 2434: > 2432: // -agentlib and -agentpath > 2433: } else if (match_option(option, "-agentlib:", &tail) || > 2434: (is_absolute_path = match_option(option, "-agentpath:", &tail))) { I think jdk.module.illegalAccess can also be removed from lines 1332 and 2064 of arguments.cpp. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From cjplummer at openjdk.java.net Thu May 13 18:03:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 13 May 2021 18:03:59 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 23:21:51 GMT, Chris Plummer wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. > @plummercj - Are you still planning to review this new test? Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From pchilanomate at openjdk.java.net Thu May 13 18:07:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 13 May 2021 18:07:59 GMT Subject: Integrated: 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition In-Reply-To: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> References: <59i74yjM3JAwY1IOe7OckvcSxVRVPzHqydGvLVS0i-0=.f3ef6734-679a-4367-adc4-2301f5014c0c@github.com> Message-ID: <8zuCYH_Ebt6NJLQ_GgeZgLAX0zj0OWTDSy1hdRsbWks=.0b63a3e0-500b-44d8-94c2-ccdd3edc0f39@github.com> On Fri, 7 May 2021 14:54:49 GMT, Patricio Chilano Mateo wrote: > Hi, > > Please review the following patch which contains the following cleanups: > > - Move _suspend_flags from Thread class to JavaThread > > - Rename _special_runtime_exit_condition to _async_exception_condition. The name has been mixed up with the methods has_special_runtime_exit_condition() and handle_special_runtime_exit_condition() which check both async exception conditions and _suspend_flags. Also rename related methods: clear_special_runtime_exit_condition() -> clear_async_exception_condition(), has_async_condition() -> has_async_exception_condition(). I also added set_async_exception_condition() just for completeness which is now called by set_pending_unsafe_access_error() and set_pending_async_exception(). > > - The _has_async_exception enum value in SuspendFlags creates a coupling between _suspend_flags and asynchronous exceptions. This allows us in the transition from native to Java wrappers to do a single load and comparison against the _suspend_flags field instead of having to do one for _suspend_flags and one for asynchronous exceptions. Since this is just an optimization I removed methods has_async_exception(), set_has_async_exception() and clear_has_async_exception() associated with _suspend_flags since they create confusion as to who actually manages asynchronous exceptions. Methods associated with _async_exception_condition should be used instead. I added a comment in set_pending_async_exception() as to why we use _suspend_flags. > > - Remove boolean parameter check_unsafe_error from check_and_handle_async_exceptions(). When we check for async exceptions we always process any async condition except in the transition from native->Java where we skip unsafe access error ones. I moved the boolean parameter to has_async_exception_condition() instead and fixed check_special_condition_for_native_trans(). Method check_and_handle_async_exceptions() could use some further cleanup but I'll do that in another RFR. > > Tested in mach5 tiers 1-6. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 853ffdb2 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/853ffdb25c76637555fa732f5e05024243747a70 Stats: 245 lines in 7 files changed: 107 ins; 116 del; 22 mod 8265934: Cleanup _suspend_flags and _special_runtime_exit_condition Reviewed-by: rehn, dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3919 From mr at openjdk.java.net Thu May 13 18:11:30 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 13 May 2021 18:11:30 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Remove stray mentions of the jdk.module.illegalAccess property ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4015/files - new: https://git.openjdk.java.net/jdk/pull/4015/files/4e2cbf93..719ff4ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015 From mr at openjdk.java.net Thu May 13 18:11:34 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 13 May 2021 18:11:34 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 17:37:42 GMT, Harold Seigel wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > src/hotspot/share/runtime/arguments.cpp line 2434: > >> 2432: // -agentlib and -agentpath >> 2433: } else if (match_option(option, "-agentlib:", &tail) || >> 2434: (is_absolute_path = match_option(option, "-agentpath:", &tail))) { > > I think jdk.module.illegalAccess can also be removed from lines 1332 and 2064 of arguments.cpp. > Thanks, Harold Good point ? fixed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From mchung at openjdk.java.net Thu May 13 18:18:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 13 May 2021 18:18:53 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 18:11:30 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Remove stray mentions of the jdk.module.illegalAccess property There are a few tests with `--illegal-access=deny` for example test/jdk/java/lang/ModuleTests/BasicModuleTest.java test/jdk/java/lang/instrument/RedefineModuleTest.java test/jdk/java/lang/invoke/CallerSensitiveAccess.java test/jdk/java/lang/reflect/AccessibleObject/ - a few tests test/jdk/jdk/modules/open/Basic.java test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java It would be good to remove these references to `--illegal-access` option in this patch too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From mr at openjdk.java.net Thu May 13 23:07:07 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 13 May 2021 23:07:07 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Remove now-unnecessary uses and mentions of the --illegal-access option ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4015/files - new: https://git.openjdk.java.net/jdk/pull/4015/files/719ff4ee..1c14998e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=01-02 Stats: 26 lines in 10 files changed: 0 ins; 8 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015 From mr at openjdk.java.net Thu May 13 23:07:08 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 13 May 2021 23:07:08 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2] In-Reply-To: References: Message-ID: <21uRRgGzIydMlvMriHNpwJZ8Of4oIquShc8me0vWLfE=.bf969916-6227-41c1-afb5-9652459f33e2@github.com> On Thu, 13 May 2021 18:16:23 GMT, Mandy Chung wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > There are a few tests with `--illegal-access=deny` for example > > test/jdk/java/lang/ModuleTests/BasicModuleTest.java > test/jdk/java/lang/instrument/RedefineModuleTest.java > test/jdk/java/lang/invoke/CallerSensitiveAccess.java > test/jdk/java/lang/reflect/AccessibleObject/ - a few tests > test/jdk/jdk/modules/open/Basic.java > test/jdk/tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java > > > It would be good to remove these references to `--illegal-access` option in this patch too. @mlchung Thanks for pointing out those stray uses of `--illegal-access`. I?ve removed them, along with the mention of `--illegal-access` in `launcher.properties`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From mchung at openjdk.java.net Thu May 13 23:16:41 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 13 May 2021 23:16:41 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3] In-Reply-To: References: Message-ID: <0MBdE4SVoC_DjdoPcM_npW286VcPBc7kVv31PS7fbQM=.f58f1848-606e-40ee-8a17-06f0d079d181@github.com> On Thu, 13 May 2021 23:07:07 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Remove now-unnecessary uses and mentions of the --illegal-access option Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4015 From darcy at openjdk.java.net Fri May 14 04:45:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 14 May 2021 04:45:11 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v6] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Respond to review feedback. - 8266530: HotSpot changes for JEP 306 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/5eb74621..8925f992 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=04-05 Stats: 11027 lines in 407 files changed: 3268 ins; 4624 del; 3135 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From darcy at openjdk.java.net Fri May 14 04:45:12 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 14 May 2021 04:45:12 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v5] In-Reply-To: <8aRBe9Qaf0ztWgSoA_akBA-vlWPf2Rn2M7AiAVEYres=.3c5764ff-0521-489f-afb5-3427044b3a4a@github.com> References: <8aRBe9Qaf0ztWgSoA_akBA-vlWPf2Rn2M7AiAVEYres=.3c5764ff-0521-489f-afb5-3427044b3a4a@github.com> Message-ID: On Thu, 13 May 2021 01:41:52 GMT, David Holmes wrote: > > > Sub-task "JDK-8266950: Remove vestigial support for non-strict floating-point execution" is being used to change the hotspot code so that `is_strict` is replaced by true and the resulting code modified accordingly. This PR will focus only on the handling of the ACC_STRICT flag during classfile parsing. Prior state of this PR restored. This PR only updates the policy around the VM's handling of ACC_STRICT and adds corresponding tests. David's PR for 8266950 covers the refactoring and cleanup inside the HotSpot code from only having support for a single floating-point mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From cjplummer at openjdk.java.net Fri May 14 04:48:35 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 04:48:35 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Drop exit_delta and the VMTestbase style of exiting on test failure. Overall it looks good. Some minor suggestions, most of which can be ignored if you wish. Is there a reason these tests were not placed under `test/jdk/java/lang/management`? test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70: > 68: // > 69: > 70: public class getLockOwnerName { Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: > 148: System.err.println("where:"); > 149: System.err.println(" -p ::= print debug info"); > 150: System.err.println(" time_max ::= max looping time in seconds"); `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324: > 322: > 323: // > 324: // Launch the blocker thread: The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: > 327: // - releases threadLock > 328: // > 329: if (getName().equals("blocker")) { Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From minqi at openjdk.java.net Fri May 14 05:46:25 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 05:46:25 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v3] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Added DynamicArchive::prepare_for_dynamic_dumping_at_exit to replace MetaspaceShared::regenerate_lambdaforminvokers_holders, the latter was removed. Added test case" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3953/files - new: https://git.openjdk.java.net/jdk/pull/3953/files/d8a1ac00..5bcc2e85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=01-02 Stats: 155 lines in 10 files changed: 132 ins; 16 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From minqi at openjdk.java.net Fri May 14 05:53:19 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 05:53:19 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: <9YgZhAlAZVhG0Xyd4zJ1n8Oy4EgUx7x_hjMR_6jRgzE=.6cd5a76f-260b-40c2-80c2-5386aca192cb@github.com> > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3953/files - new: https://git.openjdk.java.net/jdk/pull/3953/files/5bcc2e85..c2236e8d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From mli at openjdk.java.net Fri May 14 06:55:41 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 14 May 2021 06:55:41 GMT Subject: Integrated: JDK-8266795: Remove dead code LowMemoryDetectorDisabler In-Reply-To: References: Message-ID: On Tue, 11 May 2021 01:16:27 GMT, Hamlin Li wrote: > This is trivial change to remove dead code in low memory detector. This pull request has now been integrated. Changeset: 301095c8 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/301095c8beb2c95207636f0f61c02e0fc4d5a0a4 Stats: 28 lines in 2 files changed: 0 ins; 26 del; 2 mod 8266795: Remove dead code LowMemoryDetectorDisabler Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3964 From mli at openjdk.java.net Fri May 14 06:55:41 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 14 May 2021 06:55:41 GMT Subject: RFR: JDK-8266795: Remove dead code LowMemoryDetectorDisabler [v2] In-Reply-To: References: Message-ID: <2bj3b7bi4rkfQYaQ3m7CLumGwBljN09xMF0WU7w2cNA=.ad6764c1-ec67-4288-80ed-9ad0998fa0a4@github.com> On Tue, 11 May 2021 12:27:24 GMT, Hamlin Li wrote: >> This is trivial change to remove dead code in low memory detector. > > Hamlin Li 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 remote-tracking branch 'refs/remotes/origin/remove-LowMemoryDetectorDisabler' into remove-LowMemoryDetectorDisabler > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - remove more dead code. > - Merge branch 'openjdk:master' into remove-LowMemoryDetectorDisabler > - JDK-8266795: remove dead code LowMemoryDetectorDisabler Thanks David for your detailed review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3964 From rschmelter at openjdk.java.net Fri May 14 07:14:07 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Fri, 14 May 2021 07:14:07 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Ralf Schmelter 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: - Simplify thread_loop() - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 - Fix punctuation - Simplify code - Fix race in heap dump compression backend ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3628/files - new: https://git.openjdk.java.net/jdk/pull/3628/files/fb17cab8..1891197a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3628&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3628&range=00-01 Stats: 555249 lines in 4988 files changed: 44477 ins; 497699 del; 13073 mod Patch: https://git.openjdk.java.net/jdk/pull/3628.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3628/head:pull/3628 PR: https://git.openjdk.java.net/jdk/pull/3628 From rrich at openjdk.java.net Fri May 14 07:28:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 07:28:49 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > Ralf Schmelter 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: > > - Simplify thread_loop() > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Fix punctuation > - Simplify code > - Fix race in heap dump compression backend LGTM ?? ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From github.com+16811675+linade at openjdk.java.net Fri May 14 08:09:56 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Fri, 14 May 2021 08:09:56 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake Message-ID: Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. ------------- Commit messages: - 8266963: Reentrance condition for safepoint/handshake Changes: https://git.openjdk.java.net/jdk/pull/4028/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4028&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266963 Stats: 29 lines in 2 files changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4028.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4028/head:pull/4028 PR: https://git.openjdk.java.net/jdk/pull/4028 From alanb at openjdk.java.net Fri May 14 09:02:36 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 14 May 2021 09:02:36 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 23:07:07 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Remove now-unnecessary uses and mentions of the --illegal-access option The changes look good. I searched the test and src trees for other remaining usages "--illegal-access" and didn't find any more (except for localized resources). It's likely that some of the updated tests no longer need "/othervm". It would need a close inspection of each test to see if it still needed. test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 26: > 24: /** > 25: * @test > 26: * @requires vm.compMode != "Xcomp" I think `@requires vm.compMode != "Xcomp" was added because the test took too long with -Xcomp. I think it can be dropped now. test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 37: > 35: > 36: /** > 37: * Basic test of --illegal-access=value to deny or permit access to JDK internals. The comment should probably be updated as the test no longer tests denying or permitting access. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4015 From vlivanov at openjdk.java.net Fri May 14 10:05:59 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 10:05:59 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:34:25 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > use ClassLoaderData* as factor What about the following variant? diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp index 6fd5b9b8203..f1f1c82f591 100644 --- a/src/hotspot/share/classfile/classLoaderData.hpp +++ b/src/hotspot/share/classfile/classLoaderData.hpp @@ -325,6 +325,11 @@ class ClassLoaderData : public CHeapObj { const char* loader_name_and_id() const; Symbol* name_and_id() const { return _name_and_id; } + unsigned identity_hash() const { + unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); + return addr_bits; + } + JFR_ONLY(DEFINE_TRACE_ID_METHODS;) }; diff --git a/src/hotspot/share/prims/resolvedMethodTable.cpp b/src/hotspot/share/prims/resolvedMethodTable.cpp index 5e5761094f1..527a39f3646 100644 --- a/src/hotspot/share/prims/resolvedMethodTable.cpp +++ b/src/hotspot/share/prims/resolvedMethodTable.cpp @@ -23,6 +23,7 @@ */ #include "precompiled.hpp" +#include "classfile/classLoaderData.hpp" #include "classfile/javaClasses.hpp" #include "gc/shared/oopStorage.inline.hpp" #include "gc/shared/oopStorageSet.hpp" @@ -53,7 +54,8 @@ static const size_t GROW_HINT = 32; static const size_t ResolvedMethodTableSizeLog = 10; unsigned int method_hash(const Method* method) { - unsigned int hash = method->klass_name()->identity_hash(); + unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); + hash = (hash * 31) ^ method->klass_name()->identity_hash(); hash = (hash * 31) ^ method->name()->identity_hash(); hash = (hash * 31) ^ method->signature()->identity_hash(); return hash; ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From kevinw at openjdk.java.net Fri May 14 10:18:42 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 14 May 2021 10:18:42 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: On Thu, 13 May 2021 08:06:24 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from Thomas Marked as reviewed by kevinw (Committer). Hi David, looks good. I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure". If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From stuefe at openjdk.java.net Fri May 14 11:23:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 14 May 2021 11:23:35 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: On Thu, 13 May 2021 08:06:24 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from Thomas Hi Kevin, > If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.) My preference would be to keep the patches as concise as possible, because that makes backporting patches easier. vmError is overdue for some cleanups, but I'd prefer those concentrated in a cleanup RFE, which would give us just one commit to packport, instead of spreading cleanups over unrelated patches. Just my 5c, David may see this differently. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From ddong at openjdk.java.net Fri May 14 12:04:56 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 14 May 2021 12:04:56 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v6] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 10:02:31 GMT, Vladimir Ivanov wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> use ClassLoaderData* as factor > > What about the following variant? > > > diff --git a/src/hotspot/share/classfile/classLoaderData.hpp b/src/hotspot/share/classfile/classLoaderData.hpp > index 6fd5b9b8203..f1f1c82f591 100644 > --- a/src/hotspot/share/classfile/classLoaderData.hpp > +++ b/src/hotspot/share/classfile/classLoaderData.hpp > @@ -325,6 +325,11 @@ class ClassLoaderData : public CHeapObj { > const char* loader_name_and_id() const; > Symbol* name_and_id() const { return _name_and_id; } > > + unsigned identity_hash() const { > + unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); > + return addr_bits; > + } > + > JFR_ONLY(DEFINE_TRACE_ID_METHODS;) > }; > > diff --git a/src/hotspot/share/prims/resolvedMethodTable.cpp b/src/hotspot/share/prims/resolvedMethodTable.cpp > index 5e5761094f1..527a39f3646 100644 > --- a/src/hotspot/share/prims/resolvedMethodTable.cpp > +++ b/src/hotspot/share/prims/resolvedMethodTable.cpp > @@ -23,6 +23,7 @@ > */ > > #include "precompiled.hpp" > +#include "classfile/classLoaderData.hpp" > #include "classfile/javaClasses.hpp" > #include "gc/shared/oopStorage.inline.hpp" > #include "gc/shared/oopStorageSet.hpp" > @@ -53,7 +54,8 @@ static const size_t GROW_HINT = 32; > static const size_t ResolvedMethodTableSizeLog = 10; > > unsigned int method_hash(const Method* method) { > - unsigned int hash = method->klass_name()->identity_hash(); > + unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); > + hash = (hash * 31) ^ method->klass_name()->identity_hash(); > hash = (hash * 31) ^ method->name()->identity_hash(); > hash = (hash * 31) ^ method->signature()->identity_hash(); > return hash; @iwanowww It's okay for me, updated. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Fri May 14 12:04:55 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 14 May 2021 12:04:55 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/c7c54ae2..b02705f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=05-06 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From vlivanov at openjdk.java.net Fri May 14 12:34:36 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 12:34:36 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7] In-Reply-To: References: Message-ID: <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com> On Fri, 14 May 2021 12:04:55 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > refactor Looks good to me, but, please, wait for somebody from Runtime team to approve it. src/hotspot/share/prims/resolvedMethodTable.cpp line 56: > 54: > 55: unsigned int method_hash(const Method* method) { > 56: unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); I don't see "#include classfile/classLoaderData.hpp" in your patch. Did you verify it builds successfully? I saw a compilation failure without the include: src/hotspot/share/prims/resolvedMethodTable.cpp:56:67: error: member access into incomplete type 'ClassLoaderData' unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); ^ src/hotspot/share/memory/allocation.hpp:260:7: note: forward declaration of 'ClassLoaderData' class ClassLoaderData; ^ 1 error generated. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3901 From stuefe at openjdk.java.net Fri May 14 12:57:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 14 May 2021 12:57:55 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken Message-ID: Hi, may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. I manually tested that this fix works. Patch includes a repro case. Cheers, Thomas ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3968/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3968&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265705 Stats: 44 lines in 2 files changed: 27 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3968/head:pull/3968 PR: https://git.openjdk.java.net/jdk/pull/3968 From aph at openjdk.java.net Fri May 14 13:10:45 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 14 May 2021 13:10:45 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: <4GMKQwB4-JpRCOhimd2r_f_JnRbCogjInoTp6WcPo_U=.b5c1ff48-80ca-4885-afa1-bb158287fd70@github.com> On Tue, 11 May 2021 07:49:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From coleenp at openjdk.java.net Fri May 14 13:30:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 14 May 2021 13:30:49 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 12:04:55 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > refactor Looks good to me, with the inclusion of classLoaderData.hpp in resolvedMethodTable.hpp. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3901 From hseigel at openjdk.java.net Fri May 14 14:14:48 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 14 May 2021 14:14:48 GMT Subject: RFR: 8265694: Investigate test StressHiddenClasses.java Message-ID: Please review this trivial change to remove test test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java because, as pointed out in the review of JDK-8243287, this test is duplicated by test StressClassLoadingTest.java. Thanks, Harold ------------- Commit messages: - 8265694: Investigate test StressHiddenClasses.java Changes: https://git.openjdk.java.net/jdk/pull/4032/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4032&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265694 Stats: 90 lines in 1 file changed: 0 ins; 90 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4032/head:pull/4032 PR: https://git.openjdk.java.net/jdk/pull/4032 From lfoltan at openjdk.java.net Fri May 14 14:47:41 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Fri, 14 May 2021 14:47:41 GMT Subject: RFR: 8265694: Investigate test StressHiddenClasses.java In-Reply-To: References: Message-ID: On Fri, 14 May 2021 14:06:47 GMT, Harold Seigel wrote: > Please review this trivial change to remove test test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java because, as pointed out in the review of JDK-8243287, this test is duplicated by test StressClassLoadingTest.java. > > Thanks, Harold Looks good and trivial. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4032 From hseigel at openjdk.java.net Fri May 14 14:55:46 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 14 May 2021 14:55:46 GMT Subject: RFR: 8265694: Investigate test StressHiddenClasses.java In-Reply-To: References: Message-ID: On Fri, 14 May 2021 14:06:47 GMT, Harold Seigel wrote: > Please review this trivial change to remove test test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java because, as pointed out in the review of JDK-8243287, this test is duplicated by test StressClassLoadingTest.java. > > Thanks, Harold Thanks Lois for reviewing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/4032 From hseigel at openjdk.java.net Fri May 14 14:55:46 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 14 May 2021 14:55:46 GMT Subject: Integrated: 8265694: Investigate test StressHiddenClasses.java In-Reply-To: References: Message-ID: <_ckLuQPht9--LDRAiSBDprw7OV6ETuPF6ZzPW5fWK7g=.d077b64d-8eb3-4dc8-8bdb-adbc2e80dbaa@github.com> On Fri, 14 May 2021 14:06:47 GMT, Harold Seigel wrote: > Please review this trivial change to remove test test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java because, as pointed out in the review of JDK-8243287, this test is duplicated by test StressClassLoadingTest.java. > > Thanks, Harold This pull request has now been integrated. Changeset: 16ca370f Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/16ca370f1ac933a6aef49bd147d985e66b4c8930 Stats: 90 lines in 1 file changed: 0 ins; 90 del; 0 mod 8265694: Investigate test StressHiddenClasses.java Reviewed-by: lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/4032 From minqi at openjdk.java.net Fri May 14 15:41:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 15:41:20 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v5] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: New added DynamicArchive::prepare_for_dynamic_dumping_at_exit should be CDS only ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3953/files - new: https://git.openjdk.java.net/jdk/pull/3953/files/c2236e8d..bcbbc749 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=03-04 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From ddong at openjdk.java.net Fri May 14 16:00:09 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 14 May 2021 16:00:09 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong 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/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/b02705f0..e9c674ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Fri May 14 16:03:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 14 May 2021 16:03:46 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v7] In-Reply-To: <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com> References: <2iWHZyXol0hYutYUXe4KGOdq2sw2x-dn0iAhDzByfTo=.d855fc67-247c-4e2d-8861-fddb6bddf2bf@github.com> Message-ID: On Fri, 14 May 2021 12:31:05 GMT, Vladimir Ivanov wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> refactor > > src/hotspot/share/prims/resolvedMethodTable.cpp line 56: > >> 54: >> 55: unsigned int method_hash(const Method* method) { >> 56: unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); > > I don't see "#include classfile/classLoaderData.hpp" in your patch. Did you verify it builds successfully? I saw a compilation failure without the include: > > > src/hotspot/share/prims/resolvedMethodTable.cpp:56:67: error: member access into incomplete type 'ClassLoaderData' > unsigned int hash = method->method_holder()->class_loader_data()->identity_hash(); > ^ > src/hotspot/share/memory/allocation.hpp:260:7: note: forward declaration of 'ClassLoaderData' > class ClassLoaderData; > ^ > 1 error generated. Sorry, I only verify it with normal build parameters, and I forgot that "precompiled.hpp" might be disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From minqi at openjdk.java.net Fri May 14 16:06:02 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 16:06:02 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v6] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge with master, resolve conflict - New added DynamicArchive::prepare_for_dynamic_dumping_at_exit should be CDS only - Fix whitespace - Added DynamicArchive::prepare_for_dynamic_dumping_at_exit to replace MetaspaceShared::regenerate_lambdaforminvokers_holders, the latter was removed. Added test case" - Remove unused variables - 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive ------------- Changes: https://git.openjdk.java.net/jdk/pull/3953/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=05 Stats: 438 lines in 16 files changed: 363 ins; 31 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From iklam at openjdk.java.net Fri May 14 16:06:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 14 May 2021 16:06:03 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v5] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Fri, 14 May 2021 15:41:20 GMT, Yumin Qi wrote: >> Hi, please review >> This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. >> The old PR description: >> ------------- old ------------ >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> ------------ new ------------- >> The new fix (incremental) >> 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. >> 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. >> 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. >> 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. >> >> Tests: tier1,tier2,tier3,tier4 >> local test on runtime/cds >> local test ParallelLambdaLoadTest.java in loops without crash. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > New added DynamicArchive::prepare_for_dynamic_dumping_at_exit should be CDS only LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3953 From vlivanov at openjdk.java.net Fri May 14 16:22:40 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 16:22:40 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: <1sqBTtizLtZ7z8OXiUPfDKT6dPmVh_jS7AGEF14s8sw=.2a69246d-58ca-4b11-942b-30e5223842fa@github.com> On Fri, 14 May 2021 16:00:09 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add missing include I'll submit the patch for testing and sponsor once it is over. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3901 From minqi at openjdk.java.net Fri May 14 16:24:45 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 16:24:45 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Wed, 12 May 2021 15:41:36 GMT, Ioi Lam wrote: >>> Hi Yumin, >>> >>> I applied your patch and ran ParallelLambdaLoadTest.java for about 400 iterations and I could no longer reproduce the crash in [JDK-8266765](https://bugs.openjdk.java.net/browse/JDK-8266765). >>> >>> As I mentioned in some of the individual comments, we need to properly handle the exceptions that can happen inside `MetaspaceShared::link_and_cleanup_shared_classes`. I think we should change these places: >>> >>> ``` >>> JVM_ENTRY_NO_ENV(void, JVM_BeforeHalt()) >>> // Link all classes for dynamic CDS dumping before vm exit. >>> if (DynamicDumpSharedSpaces) { >>> - MetaspaceShared::link_and_cleanup_shared_classes(THREAD); >>> + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); >>> } >>> ... >>> >>> void JavaThread::invoke_shutdown_hooks() { >>> ... >>> if (DynamicDumpSharedSpaces) { >>> - MetaspaceShared::link_and_cleanup_shared_classes(this); >>> + DynamicArchive::prepare_for_dynamic_dumping_at_exit(); >>> } >>> ``` >>> >>> And add a new function like this to catch the exception. If `link_and_cleanup_shared_classes` has thrown an exception, we should not dump the dynamic archive anymore. (We are already do that with the static archive). >>> >>> ``` >>> void DynamicArchive::prepare_for_dynamic_dumping_at_exit() { >>> EXCEPTION_MARK; >>> ResourceMark rm(THREAD); >>> MetaspaceShared::link_and_cleanup_shared_classes(THREAD); >>> if (HAS_PENDING_EXCEPTION) { >>> log_error(cds)("ArchiveClassesAtExit has failed"); >>> log_error(cds)("%s: %s", PENDING_EXCEPTION->klass()->external_name(), >>> java_lang_String::as_utf8_string(java_lang_Throwable::message(PENDING_EXCEPTION))); >>> // We cannot continue to dump the archive anymore. >>> DynamicDumpSharedSpaces = false; >>> CLEAR_PENDING_EXCEPTION; >>> } >>> } >> >> The function name should be prepare_for_dynamic_dumping since it is called when jcmd does dynamic dumping which does not exit after dumping archive. >>> >>> I would also suggest writing a new test case for the exception handling: run a program with something like `-Xmx64m -XX:ArchiveClassesAtExit`. The program should completely fill up the Java heap and exit. The dynamic archive should fail to dump due to OOM. >> >> Sure will add test for this. > >> The function name should be prepare_for_dynamic_dumping since it is called when jcmd does dynamic dumping which does not exit after dumping archive. > > This function should not be called by the jcmd code. This function catches exceptions that happens inside `MetaspaceShared::link_and_cleanup_shared_classes()`, but in your existing code, jcmd doesn't call `MetaspaceShared::link_and_cleanup_shared_classes()`. @iklam thanks for review again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From vlivanov at openjdk.java.net Fri May 14 16:32:46 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 14 May 2021 16:32:46 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: Message-ID: On Wed, 12 May 2021 05:33:14 GMT, David Holmes wrote: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David Overall, it looks very good. Thanks for taking care of compiler part, David. I think it makes sense to remove lir_div_strictfp and lir_mul_strictfp in C1 as well: https://github.com/openjdk/jdk/pull/4027 Feel free to incorporate the patch into the current PR if you agree with the change. (Passed hs-tier1 - hs-tier4 testing and x86_32 build.) Otherwise, I'll handle it as a separate PR. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3991 From iklam at openjdk.java.net Fri May 14 16:41:39 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 14 May 2021 16:41:39 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Tue, 11 May 2021 07:49:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. In the future, if we want to both CDS and >4G CCS, we can revisit this. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3968 From ccheung at openjdk.java.net Fri May 14 17:35:42 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 14 May 2021 17:35:42 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v6] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Fri, 14 May 2021 16:06:02 GMT, Yumin Qi wrote: >> Hi, please review >> This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. >> The old PR description: >> ------------- old ------------ >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> ------------ new ------------- >> The new fix (incremental) >> 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. >> 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. >> 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. >> 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. >> >> Tests: tier1,tier2,tier3,tier4 >> local test on runtime/cds >> local test ParallelLambdaLoadTest.java in loops without crash. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge with master, resolve conflict > - New added DynamicArchive::prepare_for_dynamic_dumping_at_exit should be CDS only > - Fix whitespace > - Added DynamicArchive::prepare_for_dynamic_dumping_at_exit to replace MetaspaceShared::regenerate_lambdaforminvokers_holders, the latter was removed. Added test case" > - Remove unused variables > - 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Looks good. One small nit in one of the tests. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java line 57: > 55: "1024").assertAbnormalExit(output -> { > 56: output.shouldContain("ArchiveClassesAtExit has failed") > 57: .shouldContain("java.lang.OutOfMemoryError: Java heap space"); One extra blank space before `.shouldContain` at line 57. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3953 From minqi at openjdk.java.net Fri May 14 17:53:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 17:53:38 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v6] In-Reply-To: References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Fri, 14 May 2021 17:31:27 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge with master, resolve conflict >> - New added DynamicArchive::prepare_for_dynamic_dumping_at_exit should be CDS only >> - Fix whitespace >> - Added DynamicArchive::prepare_for_dynamic_dumping_at_exit to replace MetaspaceShared::regenerate_lambdaforminvokers_holders, the latter was removed. Added test case" >> - Remove unused variables >> - 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive > > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicDumpAtOom.java line 57: > >> 55: "1024").assertAbnormalExit(output -> { >> 56: output.shouldContain("ArchiveClassesAtExit has failed") >> 57: .shouldContain("java.lang.OutOfMemoryError: Java heap space"); > > One extra blank space before `.shouldContain` at line 57. Thanks for catching the tiny difference! ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From rrich at openjdk.java.net Fri May 14 18:04:39 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 18:04:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good. Cheers, Richard. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47: > 45: JavaThread* current_java_thread = JavaThread::current(); > 46: assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm"); > 47: { Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: > 384: _waiters++; > 385: ret = simple_wait(self, millis); > 386: _waiters--; We don't own the monitor yet so you cannot modify `_waiters` here. Any reason you moved and duplicated this block? src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410: > 408: ret = simple_wait(self, millis); > 409: _waiters--; > 410: _recursions = save; The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again. src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > 50: // native for all operations. However we need to honor a suspend request, not > 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend > 52: // request// and reading the interrupt flag must be done from VM state `s/request///request/` ?? ------------- Changes requested by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From minqi at openjdk.java.net Fri May 14 18:05:09 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 14 May 2021 18:05:09 GMT Subject: RFR: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v7] In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix indent in test TestDynamicDumpAtOom.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3953/files - new: https://git.openjdk.java.net/jdk/pull/3953/files/78fbfb73..39e5ec17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3953&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3953/head:pull/3953 PR: https://git.openjdk.java.net/jdk/pull/3953 From stuefe at openjdk.java.net Fri May 14 18:07:37 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 14 May 2021 18:07:37 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Tue, 11 May 2021 07:49:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas Hi Ioi, thank you for looking at this. > Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. > > In the future, if we want to both CDS and >4G CCS, we can revisit this. I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms. Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot. If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From gziemski at openjdk.java.net Fri May 14 18:16:39 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 14 May 2021 18:16:39 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:18:19 GMT, Anton Kozlov wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Change option and method name Changes requested by gziemski (Committer). src/hotspot/share/runtime/safepointMechanism.inline.hpp line 67: > 65: } > 66: > 67: void SafepointMechanism::process_if_requested(JavaThread* thread) { Looking at the stack from the crash: V [libjvm.dylib+0x8c1060] _ZN21MarkActivationClosure12do_code_blobEP8CodeBlob+0x3c V [libjvm.dylib+0x8fea78] _ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x84 V [libjvm.dylib+0x401100] _ZN14HandshakeState18process_self_innerEv+0x18c V [libjvm.dylib+0x400f60] _ZN14HandshakeState15process_by_selfEv+0x48 V [libjvm.dylib+0x832690] _ZN18SafepointMechanism25process_if_requested_slowEP10JavaThread+0x54 V [libjvm.dylib+0x8fe4b8] _ZN10JavaThread44check_safepoint_and_suspend_for_native_transEPS_+0x24 V [libjvm.dylib+0x92395c] _ZN19ProgrammableInvoker13invoke_nativeEPFvPhES0_P10JavaThread+0x118 V [libjvm.dylib+0x923aa8] PI_invokeNative+0x104 J 2565 jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(JJ)V jdk.incubator.foreign at 17-ea (0 bytes) @ 0x00000001189eeed0 why aren't we adding the assertion closer to the frame that crashed, where we need it, like for example: `HandshakeState::process_self_inner()` ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From iklam at openjdk.java.net Fri May 14 18:27:42 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 14 May 2021 18:27:42 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:04:36 GMT, Thomas Stuefe wrote: > Hi Ioi, > > thank you for looking at this. > > > Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. > > In the future, if we want to both CDS and >4G CCS, we can revisit this. > > I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms. > > Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot. > > If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g. > > Cheers, Thomas My reasoning is -- this is platform independent code. If this patch works for aarch64, it must also work for other platforms. Conversely, If it doesn't work for any other platform, why do we believe it would work on aarch64? Since we test other platforms much more than aarch64, I think the best way to ensure that the patch works is to also turn it on for all platforms. JDK 17 repo branch happens next month, but we still have a couple of months afterwards for bug fixes. I think we have enough time to handle any problems that may happen. Lilliput is not going to happen for a while, and we can handle it when the time comes. (It's not like the existing hard-coded shift of 3 is going to be much more compatible with Liliput than 0). ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From cjplummer at openjdk.java.net Fri May 14 18:28:51 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 18:28:51 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > Ralf Schmelter 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: > > - Simplify thread_loop() > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Fix punctuation > - Simplify code > - Fix race in heap dump compression backend Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From gziemski at openjdk.java.net Fri May 14 19:01:37 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 14 May 2021 19:01:37 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: On Thu, 13 May 2021 08:06:24 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from Thomas Changes requested by gziemski (Committer). src/hotspot/share/utilities/debug.cpp line 319: > 317: report_fatal_impl(INTERNAL_ERROR, file, line, detail_fmt, detail_args); > 318: va_end(detail_args); > 319: } Do we really need this API? Can't we just update: #define fatal(...) \ do { \ TOUCH_ASSERT_POISON; \ report_fatal(INTERNAL_ERROR, __FILE__, __LINE__, __VA_ARGS__); \ BREAKPOINT; \ } while (0) ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From rrich at openjdk.java.net Fri May 14 19:45:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 19:45:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 12/05/2021 8:56 pm, Robbin Ehn wrote: > > > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > > > Hi Robbin, > > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > > Thanks, Richard. > > > > > > Hi Richard, > > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. > > Regarding ThreadClosure, we could use it, maybe that is preferable?! > > Isn't a ThreadClosure for applying an operation to a set of threads? > That is not what we are doing here. No it isn't. A closure is just a set of variable bindings and a function that can be executed. And yes we're doing just that. A ThreadClosure is just an instance of this general concept. E.g. an AsyncHandshakeClosure (subclass of ThreadClosure) is a function (plus variable bindings) that is passed by a requesting thread to a target thread to be executed by it. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Fri May 14 20:04:04 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 14 May 2021 20:04:04 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: References: Message-ID: On Fri, 14 May 2021 08:01:12 GMT, Yude Lin wrote: > Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. > > An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond > > I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. Hi Yude, Comments about the issue below. Thanks, Patricio src/hotspot/share/runtime/safepointMechanism.cpp line 157: > 155: // reentrance of the handshake mutex. We also don't need to do anything > 156: // because the process() routine will be retried after the handshake returns. > 157: return; We cannot do a return here because a safepoint could be already in progress after transitioning out of the blocked state. The handshake would then execute concurrently with the safepoint operation which is not allowed. We used to have a flag in HandshakeState to avoid these reentrant cases [1], but we removed it after we added the NoSafepointVerifier checks in handshake.cpp. I'm guessing this failed with release bits, otherwise you should have hit the assert in check_possible_safepoint() in ThreadBlockInVM. So unless we also remove the NoSafepointVerifier checks in handshake.cpp bringing that flag back would just solve this issue for release builds. I think the question is then whether it is safe to poll for safepoints inside a handshake closure. Before stackwatermarks maybe there were no issues, but now I don't think so. If ThreadA is executing a handshake on behalf of ThreadB and blocks in ThreadBlockInVM, then a safepoint could happen. After resuming I don't think it is safe for ThreadA to keep poking into ThreadB stack before doing StackWatermarkSet::start_processing() on ThreadB. Maybe @fisk could confirm? Note that the NoSafepointVerifier checks are also there to prevent requesting a VM operation inside the handshake since that can deadlock too. So even if polling would be fine we would need to keep checking that (not necessarily with NoSafepointVerifier though). [1] https://github.com/openjdk/jdk/blob/6d19fe65d1c1d8f41fd2f18afd09de134912505f/src/hotspot/share/runtime/handshake.hpp#L93 ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From iklam at openjdk.java.net Fri May 14 21:14:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 14 May 2021 21:14:59 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means [v6] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > declare has_old_class_version as a const method > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > Hi Calvin, > > On 12/05/2021 2:23 am, Calvin Cheung wrote: > > > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > I guess you missed the fact that I had changed the bug synopsis. Why not > call this needs_old_verifier (or something like that) so that the exact > meaning of this method is more clear? needs_old_verifier isn't clear, either. `has_old_class_version(K)` returns true if K is "new" but one of K's supertypes is "old". K itself does not "need the old verifier". ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From xliu at openjdk.java.net Fri May 14 22:06:48 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 14 May 2021 22:06:48 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 07:08:11 GMT, Yi Yang wrote: > While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. This is nice! It's not "seems" , we can use typedef. Another nit you can do along with this PR. move * to its class. ID2KlassTable* table() { return &_id2klass_table; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4007 From dcubed at openjdk.java.net Fri May 14 22:14:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 22:14:56 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 04:45:36 GMT, Chris Plummer wrote: > Overall it looks good. Some minor suggestions, most of which can be ignored if you wish. Thanks for the review. I made some of the changes, but not all of them. > Is there a reason these tests were not placed under test/jdk/java/lang/management? These tests are for stressing particular HotSpot implementation pieces that are used by the M&M APIs. In particular, they are stressing the use of ThreadsListHandles in both the safepoint and non-safepoint code paths traveled by getThreadInfo(): // maxDepth == 0 requires no safepoint so alternate. int maxDepth = ((count % 1) == 1) ? Integer.MAX_VALUE : 0; info = mbean.getThreadInfo(id, maxDepth); if (info == null) { // the contender has exited break; } name = info.getLockOwnerName(); And we're stressing getLockOwnerName() because we had a non-reproducible bug that crashed in that particular function after the getThreadInfo() call. So I think this stress test (along with others that I've written in this family) belong in the test/hotspot collection of tests. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70: > >> 68: // >> 69: >> 70: public class getLockOwnerName { > > Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name. Looks like I did that because the API is called: ThreadInfo.getLockOwnerName() Will fix the filenames and the classname. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: > >> 148: System.err.println("where:"); >> 149: System.err.println(" -p ::= print debug info"); >> 150: System.err.println(" time_max ::= max looping time in seconds"); > > `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. It's a grammar notational style from my compiler theory days. I've used '::=' and ':=' for years. What would you like it changed to? Or can I just leave it and try to use '-' in the future? > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324: > >> 322: >> 323: // >> 324: // Launch the blocker thread: > > The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads. Fixed. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: > >> 327: // - releases threadLock >> 328: // >> 329: if (getName().equals("blocker")) { > > Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. This new test is a variation of a 20 year old test that I recently ported to JVM/TI and integrated. 20 years ago, it was much simpler to write the test this way. I could create a separate Thread subclass for each "role", but I'd rather not do that since it will no longer be easy to compare this test to its siblings. As for lambdas, I know absolutely zero about writing lambda code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From xliu at openjdk.java.net Fri May 14 22:15:35 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 14 May 2021 22:15:35 GMT Subject: RFR: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed In-Reply-To: References: Message-ID: On Thu, 13 May 2021 15:39:49 GMT, Thomas Stuefe wrote: > My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). > > Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. > > Tested manually with various time zones. LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/4013 From dcubed at openjdk.java.net Fri May 14 22:20:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 22:20:31 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v6] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: plummercj CR changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/771dafee..6a8e5e37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=04-05 Stats: 831 lines in 3 files changed: 415 ins; 415 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Fri May 14 22:44:54 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 22:44:54 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 21:54:46 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: >> >>> 148: System.err.println("where:"); >>> 149: System.err.println(" -p ::= print debug info"); >>> 150: System.err.println(" time_max ::= max looping time in seconds"); >> >> `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. > > It's a grammar notational style from my compiler theory days. > I've used '::=' and ':=' for years. What would you like it changed to? > Or can I just leave it and try to use '-' in the future? The convention for java tools seems to be to just use tabs to align the start of the argument descriptions: -p print debug info time_max max looping time in seconds ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Fri May 14 22:57:39 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 22:57:39 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 22:04:05 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: >> >>> 327: // - releases threadLock >>> 328: // >>> 329: if (getName().equals("blocker")) { >> >> Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. > > This new test is a variation of a 20 year old test that I recently ported to JVM/TI > and integrated. 20 years ago, it was much simpler to write the test this way. > I could create a separate Thread subclass for each "role", but I'd rather not > do that since it will no longer be easy to compare this test to its siblings. > > As for lambdas, I know absolutely zero about writing lambda code. Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them: // create thread with specified method as the "run" method Thread t = new Thread(this::testMethod); t.start(); // create thread with the specified code block as the "run" method Thread t1 = new Thread(() -> { synchronized (lock1) { System.out.println("Thread in sync section 1: " + Thread.currentThread().getName()); test1(); } // create a static Runnable object using a lambda and use it as the Runnable for a new Thread static final Runnable CONSUMER = () -> { remove(QUEUE); }; ... Thread t = new Thread(CONSUMER); ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:45:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:45:37 GMT Subject: RFR: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed In-Reply-To: References: Message-ID: <7D_8tnWSOKhjZpz9jqZ-6zyvt0S-r09Ud9ChX15wK_4=.25b64a18-4543-4df7-af33-b7dd939169a5@github.com> On Thu, 13 May 2021 15:39:49 GMT, Thomas Stuefe wrote: > My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). > > Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. > > Tested manually with various time zones. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4013 From dcubed at openjdk.java.net Fri May 14 23:58:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:03 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Thu, 13 May 2021 18:01:27 GMT, Chris Plummer wrote: >> When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. > >> @plummercj - Are you still planning to review this new test? > > Yes @plummercj - please mark this as 'Reviewed' if this latest version is acceptable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:58:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:03 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: plummercj CR - drop '::=' from the usage() output. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/6a8e5e37..185ee0f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:58:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:04 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 22:41:28 GMT, Chris Plummer wrote: >> It's a grammar notational style from my compiler theory days. >> I've used '::=' and ':=' for years. What would you like it changed to? >> Or can I just leave it and try to use '-' in the future? > > The convention for java tools seems to be to just use tabs to align the start of the argument descriptions: > > > -p print debug info > time_max max looping time in seconds Fixed. >> This new test is a variation of a 20 year old test that I recently ported to JVM/TI >> and integrated. 20 years ago, it was much simpler to write the test this way. >> I could create a separate Thread subclass for each "role", but I'd rather not >> do that since it will no longer be easy to compare this test to its siblings. >> >> As for lambdas, I know absolutely zero about writing lambda code. > > Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them: > > > // create thread with specified method as the "run" method > Thread t = new Thread(this::testMethod); > t.start(); > > > > // create thread with the specified code block as the "run" method > Thread t1 = new Thread(() -> { > synchronized (lock1) { > System.out.println("Thread in sync section 1: " > + Thread.currentThread().getName()); > test1(); > } > > > > // create a static Runnable object using a lambda and use it as the Runnable for a new Thread > static final Runnable CONSUMER = () -> { > remove(QUEUE); > }; > ... > Thread t = new Thread(CONSUMER); I'll pass on the lambdas. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Sat May 15 03:00:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 15 May 2021 03:00:40 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 23:58:03 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > plummercj CR - drop '::=' from the usage() output. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From iklam at openjdk.java.net Sat May 15 03:10:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 15 May 2021 03:10:35 GMT Subject: RFR: 8266891: Provide a switch to force the class space to a specific location In-Reply-To: References: Message-ID: On Tue, 11 May 2021 08:52:55 GMT, Thomas Stuefe wrote: > To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time. > > For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3969 From stuefe at openjdk.java.net Sat May 15 05:22:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 15 May 2021 05:22:40 GMT Subject: RFR: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed In-Reply-To: References: Message-ID: On Fri, 14 May 2021 22:12:50 GMT, Xin Liu wrote: >> My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). >> >> Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. >> >> Tested manually with various time zones. > > LGTM. @navyxliu , @dcubed-ojdk Thanks for reviewing! Strictly speaking this does not yet fulfill the requirements of 2 reviewers, since @navyxliu is no committer yet, but I declare this patch retroactively trivial (should have done this right away). ------------- PR: https://git.openjdk.java.net/jdk/pull/4013 From stuefe at openjdk.java.net Sat May 15 05:22:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 15 May 2021 05:22:41 GMT Subject: Integrated: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed In-Reply-To: References: Message-ID: On Thu, 13 May 2021 15:39:49 GMT, Thomas Stuefe wrote: > My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). > > Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. > > Tested manually with various time zones. This pull request has now been integrated. Changeset: f3fb5a45 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/f3fb5a4524255487f95a93e50da6b230de0b31ce Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4013 From stuefe at openjdk.java.net Sat May 15 05:27:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 15 May 2021 05:27:35 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:22:39 GMT, Ioi Lam wrote: > > Hi Ioi, > > thank you for looking at this. > > > Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. > > > In the future, if we want to both CDS and >4G CCS, we can revisit this. > > > > > > I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms. > > Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot. > > If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g. > > Cheers, Thomas > > My reasoning is -- this is platform independent code. If this patch works for aarch64, it must also work for other platforms. Conversely, If it doesn't work for any other platform, why do we believe it would work on aarch64? > Okay, I'll do it. > Since we test other platforms much more than aarch64, I think the best way to ensure that the patch works is to also turn it on for all platforms. > > JDK 17 repo branch happens next month, but we still have a couple of months afterwards for bug fixes. I think we have enough time to handle any problems that may happen. > > Lilliput is not going to happen for a while, and we can handle it when the time comes. (It's not like the existing hard-coded shift of 3 is going to be much more compatible with Liliput than 0). No, not a shift of 3. But I think a much larger shift may be interesting again, e.g. 8. This would require a couple of adjustments, but could shrink the pointer to 24 bits acc. to my thinking. ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From stuefe at openjdk.java.net Sat May 15 05:44:06 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 15 May 2021 05:44:06 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken [v2] In-Reply-To: References: Message-ID: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: zero shift for cds=on/dump on all platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3968/files - new: https://git.openjdk.java.net/jdk/pull/3968/files/16246025..49efdb5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3968&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3968&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3968.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3968/head:pull/3968 PR: https://git.openjdk.java.net/jdk/pull/3968 From stuefe at openjdk.java.net Sat May 15 05:44:06 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 15 May 2021 05:44:06 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Tue, 11 May 2021 07:49:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas I set the shift to zero. I will hold off integrating this change to wait for test results on all our platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From github.com+16811675+linade at openjdk.java.net Sat May 15 08:04:36 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Sat, 15 May 2021 08:04:36 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: References: Message-ID: On Fri, 14 May 2021 19:49:10 GMT, Patricio Chilano Mateo wrote: > We cannot do a return here because a safepoint could be already in progress after transitioning out of the blocked state. The handshake would then execute concurrently with the safepoint operation which is not allowed. I didn't get this part. Being able to return means that we are already in another enclosing SafepointMechanism::process_if_requested_slow(). This enclosing SafepointMechanism::process_if_requested_slow() should make sure we are processing the handshake safely, right? > We used to have a flag in HandshakeState to avoid these reentrant cases I think this flag should also prevent reentrant handshake. > I'm guessing this failed with release bits, otherwise you should have hit the assert in check_possible_safepoint() in ThreadBlockInVM. It's indeed release build. But fastdebug build miraculously runs without any hang or crash. Maybe it took a different path. While I was figuring out why the debug build won't crash. I found that the condition `i != 0` in do_interpretation (if I understand correctly, it's just a spin count) could be hiding the reentrance problem. If I make the change diff --git a/src/hotspot/share/oops/generateOopMap.cpp b/src/hotspot/share/oops/generateOopMap.cpp index 06ae6b0dbaf..8048aa92fc6 100644 --- a/src/hotspot/share/oops/generateOopMap.cpp +++ b/src/hotspot/share/oops/generateOopMap.cpp @@ -911,7 +911,7 @@ void GenerateOopMap::do_interpretation(Thread* thread) { int i = 0; do { - if (i != 0 && thread->is_Java_thread()) { + if (thread->is_Java_thread()) { JavaThread* jt = thread->as_Java_thread(); if (jt->thread_state() == _thread_in_vm) { // Since this JavaThread has looped at least once and is _thread_in_vm, I get # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/yude.lyd/jdk-master/src/hotspot/share/runtime/mutex.cpp:407), pid=122250, tid=123348 # assert(false) failed: Attempting to acquire lock tty_lock/3 out of order with lock stack_watermark_lock/2 -- possible deadlock # # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-adhoc.yudelyd.jdk-master) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.yudelyd.jdk-master, mixed mode, sharing, compressed oops, compressed class ptrs, shenandoah gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x1485e50] Mutex::check_rank(Thread*)+0x120 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Xmx24g -Xms24g -XX:ParallelGCThreads=16 -XX:+UseShenandoahGC -XX:-TieredCompilation -Xlog:gc*=debug,handshake=trace:file=510s.log:tid:filesize=200m SPECjvm2008.jar -ict -coe -i 5 derby XXXX, Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz, 96 cores, 503G, XXXX Time: Sat May 15 15:32:28 2021 CST elapsed time: 101.087584 seconds (0d 0h 1m 41s) --------------- T H R E A D --------------- Current thread (0x00007f5ca802ecc0): JavaThread "BenchmarkThread derby 51" [_thread_in_vm, id=123348, stack(0x00007f5b8b4f5000,0x00007f5b8b5f6000)] Stack: [0x00007f5b8b4f5000,0x00007f5b8b5f6000], sp=0x00007f5b8b5f1f20, free space=1011k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1485e50] Mutex::check_rank(Thread*)+0x120 V [libjvm.so+0x14867f1] Mutex::lock_without_safepoint_check(Thread*)+0x51 V [libjvm.so+0x1541090] defaultStream::hold(long)+0xa0 V [libjvm.so+0x154124a] defaultStream::write(char const*, unsigned long)+0x2a V [libjvm.so+0x153dc30] outputStream::do_vsnprintf_and_write_with_automatic_buffer(char const*, __va_list_tag*, bool)+0xf0 V [libjvm.so+0x153e97f] outputStream::print_cr(char const*, ...)+0x1bf V [libjvm.so+0x1981063] JavaThread::check_possible_safepoint()+0x63 V [libjvm.so+0xd2f838] GenerateOopMap::do_interpretation(Thread*)+0x238 V [libjvm.so+0xd2fe0e] GenerateOopMap::compute_map(Thread*)+0x3ae V [libjvm.so+0x150d243] OopMapForCacheEntry::compute_map(Thread*)+0x163 V [libjvm.so+0x150eef5] OopMapCacheEntry::fill(methodHandle const&, int)+0xf5 V [libjvm.so+0x150fa40] OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x60 V [libjvm.so+0x141d876] Method::mask_for(int, InterpreterOopMap*)+0x96 V [libjvm.so+0xbd6381] frame::oops_interpreted_do(OopClosure*, RegisterMap const*, bool) const+0x4c1 V [libjvm.so+0x185073e] StackWatermarkFramesIterator::process_one(void*)+0x20e V [libjvm.so+0x18515f8] StackWatermark::process_one()+0x88 V [libjvm.so+0x18526e9] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0x89 V [libjvm.so+0xbd98ca] frame::sender(RegisterMap*) const+0x7a V [libjvm.so+0x167f988] check_compiled_frame(JavaThread*)+0x88 V [libjvm.so+0x168397a] OptoRuntime::new_instance_C(Klass*, JavaThread*)+0xfa ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From dcubed at openjdk.java.net Sat May 15 13:11:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 15 May 2021 13:11:53 GMT Subject: RFR: JDK-8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed In-Reply-To: References: Message-ID: On Thu, 13 May 2021 15:39:49 GMT, Thomas Stuefe wrote: > My test only worked on half the globe, since the timezone stamp comparison was wrong (always compared for '+'). > > Fixed that. Also made the UTC-variant-tests more strict by requiring the timezone delta to be 0000. > > Tested manually with various time zones. I concur that this is a trivial fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4013 From dcubed at openjdk.java.net Sat May 15 13:17:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 15 May 2021 13:17:42 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 08:12:22 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop exit_delta and the VMTestbase style of exiting on test failure. > > Hi Dan, > > Seems fine. Thanks for the updates. > > The proof of a test is in its execution :) > > David @dholmes-ora and @plummercj - Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Sat May 15 13:17:45 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 15 May 2021 13:17:45 GMT Subject: Integrated: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. This pull request has now been integrated. Changeset: 8c71144a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/8c71144a2392b8d2ce47074c819d56e523b50145 Stats: 503 lines in 2 files changed: 503 ins; 0 del; 0 mod 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From minqi at openjdk.java.net Sun May 16 02:29:23 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Sun, 16 May 2021 02:29:23 GMT Subject: Integrated: 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> References: <143SgSu2_wwVk6FyGBJlamymHRoSUlLZU6MZDC1dRPo=.9b1da7c9-c921-428b-b595-1e8f639d548a@github.com> Message-ID: On Mon, 10 May 2021 17:48:51 GMT, Yumin Qi wrote: > Hi, please review > This is REDO for jdk-8255493, the integration of the fix caused ParallelLambdaLoadTest.java failed. > The old PR description: > ------------- old ------------ > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > ------------ new ------------- > The new fix (incremental) > 1) Added a lock to protect LambdaFormInvokers::_lambdaform_lines, at dynamic dump case, there are potentially concurrent issue the list is added from multiple threads at same time regeneration of holder class is reading from the list. > 2) Added a new function to MetaspaceShared, MetaspaceShared::regenerate_lambdaforminvokers_holders which calls into LambdaFormInvokers::LambdaFormInvokers::regenerate_holder_classes, and handle exceptions, this way even the regeneration fails, no affect to normal dump process. > 3) Move the call to regenerate holder classes to MetaspaceShared::link_and_cleanup_shared_classes, this is before java shutdown hook execution, since after that, it is not safe to call into java. > 4) Since change in 3), jcmd to dynamic dump, we need call MetaspaceShared::regenerate_lambdaforminvokers_holders before do dumping. > > Tests: tier1,tier2,tier3,tier4 > local test on runtime/cds > local test ParallelLambdaLoadTest.java in loops without crash. > > Thanks > Yumin This pull request has now been integrated. Changeset: 2066f497 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/2066f497b9677971ece0b8a4d855f87a2f4c4018 Stats: 438 lines in 16 files changed: 363 ins; 31 del; 44 mod 8266764: [REDO] JDK-8255493 Support for pre-generated java.lang.invoke classes in CDS dynamic archive Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3953 From stuefe at openjdk.java.net Sun May 16 07:12:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 16 May 2021 07:12:15 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake Message-ID: Hi, May I have reviews for this very simple change (triggered by this ML discussion [1]): On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake. The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake. I ran OPs [1] test on my machine and with logging to a very fast ssd enabled: thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest Duration: 5191 with this patch test time drops by about 19%: thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest Duration: 4228 No perceptible difference with logging disabled, as it should be. --- (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.) [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/4042/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4042&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267209 Stats: 12 lines in 2 files changed: 6 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4042.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4042/head:pull/4042 PR: https://git.openjdk.java.net/jdk/pull/4042 From dholmes at openjdk.java.net Sun May 16 22:54:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 16 May 2021 22:54:53 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: Message-ID: On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews for this very simple change (triggered by this ML discussion [1]): > > On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake. > > The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake. > > I ran OPs [1] test on my machine and with logging to a very fast ssd enabled: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 5191 > > > with this patch test time drops by about 19%: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 4228 > > > No perceptible difference with logging disabled, as it should be. > > --- > > (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.) > > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html Hi Thomas, This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :( As Linux/BSD/macOS can't start threads suspended we have to emulate that with this handshake. The reason this is/was needed is to ensure the newly created thread can't run to completion and delete itself before the creator has finished the initial interaction with it. Cheers, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4042 From david.holmes at oracle.com Mon May 17 00:54:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 10:54:24 +1000 Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: Message-ID: <36e73a59-6772-a34a-86e5-068fe4ac609f@oracle.com> Sorry I read things too quickly ... On 17/05/2021 8:54 am, David Holmes wrote: > On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe wrote: > >> Hi, >> >> May I have reviews for this very simple change (triggered by this ML discussion [1]): >> >> On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake. >> >> The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake. >> >> I ran OPs [1] test on my machine and with logging to a very fast ssd enabled: >> >> >> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest >> Duration: 5191 >> >> >> with this patch test time drops by about 19%: >> >> >> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest >> Duration: 4228 >> >> >> No perceptible difference with logging disabled, as it should be. >> >> --- >> >> (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.) >> >> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html > > Hi Thomas, > > This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :( Misread the problem. I thought the logging was an issue even when disabled. With it enabled I don't really care if it causes a lag in the handshake. To me this is not an issue. David > As Linux/BSD/macOS can't start threads suspended we have to emulate that with this handshake. The reason this is/was needed is to ensure the newly created thread can't run to completion and delete itself before the creator has finished the initial interaction with it. > > Cheers, > David > > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4042 > From dholmes at openjdk.java.net Mon May 17 01:38:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 01:38:47 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 17:53:15 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: > >> 384: _waiters++; >> 385: ret = simple_wait(self, millis); >> 386: _waiters--; > > We don't own the monitor yet so you cannot modify `_waiters` here. > Any reason you moved and duplicated this block? Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait. This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Mon May 17 02:05:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 02:05:39 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: <9BPk3JgF8s0DAvwM8tssJFvyqd0FyQ8mv2EaiO7iqLA=.43e5a6e0-2947-4920-bcbc-9907d6615d22@github.com> On Fri, 14 May 2021 18:56:48 GMT, Gerard Ziemski wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from Thomas > > src/hotspot/share/utilities/debug.cpp line 319: > >> 317: report_fatal_impl(INTERNAL_ERROR, file, line, detail_fmt, detail_args); >> 318: va_end(detail_args); >> 319: } > > Do we really need this API? Can't we just update: > > > #define fatal(...) \ > do { \ > TOUCH_ASSERT_POISON; \ > report_fatal(INTERNAL_ERROR, __FILE__, __LINE__, __VA_ARGS__); \ > BREAKPOINT; \ > } while (0) As the fatal() macro seems to be the only user of the existing `report_fatal` then yes I think we can simplify this as you suggest. I had thought it was used directly from elsewhere. Thanks for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From david.holmes at oracle.com Mon May 17 02:17:32 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 12:17:32 +1000 Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v2] In-Reply-To: References: <5sWhhSJn17Abpc5zq2cGGErFyFS_-cbhGNG1IN3YRCA=.67a09dc7-02f0-44fe-8fbc-148bbd29da39@github.com> Message-ID: <5ebd07df-6235-d3b5-d224-4b1cd22d6af3@oracle.com> Hi Kevin, Thanks for looking at this. On 14/05/2021 8:18 pm, Kevin Walls wrote: > On Thu, 13 May 2021 08:06:24 GMT, David Holmes wrote: > >>> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >>> >>> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >>> >>> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >>> >>> Tested tiers 1-3 for good measure. >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from Thomas > > Marked as reviewed by kevinw (Committer). > > Hi David, looks good. > > I get it now I've found that should_report_bug() really means "is vm internal error". Literally, "is this NOT a native memory allocation failure". > > If you had time to rename should_report_bug() "is_internal_error" or similar, I think that would make vmError.cpp significantly more readable. (It's not a problem in the function you're adding, it's the old should_report_bug that seems misnamed, and more so now it has a similar related function.) I couldn't determine exactly what "should_report_error" was really trying to distinguish, beyond the obvious case of "report the bug submit URL". As Thomas notes there is potential for more rework in this area, but I don't want to increase the scope of the current change. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4006 > From yyang at openjdk.java.net Mon May 17 02:24:49 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 17 May 2021 02:24:49 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 07:08:11 GMT, Yi Yang wrote: > While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. > This is nice! It's not "seems" , we can use typedef. > > Another nit you can do along with this PR. move * to its class. > > ```c++ > ID2KlassTable* table() { > return &_id2klass_table; > } > ``` Hi Xin, do you mean `typedef KVHashtable* ID2KlassTable`? This is not feasible since _id2klass_table is not a type of pointer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4007 From dholmes at openjdk.java.net Mon May 17 02:27:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 02:27:10 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v3] In-Reply-To: References: Message-ID: > A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. > > VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. > > Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. > > Tested tiers 1-3 for good measure. > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Simplify API changes based on Gerard's suggestion. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4006/files - new: https://git.openjdk.java.net/jdk/pull/4006/files/147b5cf1..8ff19358 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4006&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4006&range=01-02 Stats: 25 lines in 2 files changed: 2 ins; 21 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4006.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4006/head:pull/4006 PR: https://git.openjdk.java.net/jdk/pull/4006 From stuefe at openjdk.java.net Mon May 17 05:40:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 05:40:38 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: <36e73a59-6772-a34a-86e5-068fe4ac609f@oracle.com> References: <36e73a59-6772-a34a-86e5-068fe4ac609f@oracle.com> Message-ID: On Mon, 17 May 2021 00:56:13 GMT, David Holmes wrote: > > Hi Thomas, > > This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :( > > Misread the problem. I thought the logging was an issue even when > disabled. With it enabled I don't really care if it causes a lag in the > handshake. To me this is not an issue. > To me it is, since logging should disturb the timing behaviour of the VM as little as possible. Especially if the fix is that simple. ..Thomas > David ------------- PR: https://git.openjdk.java.net/jdk/pull/4042 From stuefe at openjdk.java.net Mon May 17 05:44:44 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 05:44:44 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 02:27:10 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Simplify API changes based on Gerard's suggestion. Looks still good. ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From stuefe at openjdk.java.net Mon May 17 05:45:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 05:45:41 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: Message-ID: On Sun, 16 May 2021 22:52:12 GMT, David Holmes wrote: > Hi Thomas, > > This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :( > > As Linux/BSD/macOS can't start threads suspended we have to emulate that with this handshake. The reason this is/was needed is to ensure the newly created thread can't run to completion and delete itself before the creator has finished the initial interaction with it. > > Cheers, > David Thanks for the Review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/4042 From xliu at openjdk.java.net Mon May 17 05:47:17 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 17 May 2021 05:47:17 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 07:08:11 GMT, Yi Yang wrote: > While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. I think you patch looks good. in particular, you tuck away ID2KlassTable in . That increases encapsulation. I mean you can change the return type of `table()` to 'ID2KlassTable*[whitespace]'. In hotspot cod style, pointer '*' is close to its type. ------------- PR: https://git.openjdk.java.net/jdk/pull/4007 From ngasson at openjdk.java.net Mon May 17 05:54:39 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 17 May 2021 05:54:39 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken [v2] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 05:44:06 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. >> >> I manually tested that this fix works. Patch includes a repro case. >> >> Cheers, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > zero shift for cds=on/dump on all platforms I've tested tier1 on AArch64 (not a Reviewer). ------------- Marked as reviewed by ngasson (Committer). PR: https://git.openjdk.java.net/jdk/pull/3968 From yyang at openjdk.java.net Mon May 17 06:00:33 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 17 May 2021 06:00:33 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable [v2] In-Reply-To: References: Message-ID: > While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: ID2KlassTable* instead of ID2KlassTable * ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4007/files - new: https://git.openjdk.java.net/jdk/pull/4007/files/8a1b16bd..dcd4564c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4007&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4007&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4007.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4007/head:pull/4007 PR: https://git.openjdk.java.net/jdk/pull/4007 From yyang at openjdk.java.net Mon May 17 06:00:34 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 17 May 2021 06:00:34 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable In-Reply-To: References: Message-ID: On Mon, 17 May 2021 05:43:16 GMT, Xin Liu wrote: > I think you patch looks good. in particular, you tuck away ID2KlassTable in . That increases encapsulation. > > I mean you can change the return type of `table()` to 'ID2KlassTable*[whitespace]'. > In hotspot cod style, pointer '*' is close to its type. Good catch! Changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4007 From david.holmes at oracle.com Mon May 17 06:03:06 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 16:03:06 +1000 Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means [v6] In-Reply-To: References: Message-ID: On 15/05/2021 7:14 am, Ioi Lam wrote: > On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: > >>> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >>> >>> Tests: >>> - [x] tier1, 2 >> >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> declare has_old_class_version as a const method > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ >> >> Hi Calvin, >> >> On 12/05/2021 2:23 am, Calvin Cheung wrote: >> >>> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> I guess you missed the fact that I had changed the bug synopsis. Why not >> call this needs_old_verifier (or something like that) so that the exact >> meaning of this method is more clear? > > needs_old_verifier isn't clear, either. `has_old_class_version(K)` returns true if K is "new" but one of K's supertypes is "old". K itself does not "need the old verifier". and k itself does not "have an old class version" so the current method is even more misleadingly named! How about inverting it and having has_post_Java_6_hierarchy: return true if k and all its supertypes are post-Java-6 classfile version. Seriously we must be able to name this method in a more meaningful way. :( David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3983 > From david.holmes at oracle.com Mon May 17 06:18:10 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 16:18:10 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: Message-ID: Hi Vladimir, Thanks for the review! On 15/05/2021 2:32 am, Vladimir Ivanov wrote: > On Wed, 12 May 2021 05:33:14 GMT, David Holmes wrote: > >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > Overall, it looks very good. > Thanks for taking care of compiler part, David. > > I think it makes sense to remove lir_div_strictfp and lir_mul_strictfp in C1 as well: > https://github.com/openjdk/jdk/pull/4027 > > Feel free to incorporate the patch into the current PR if you agree with the change. > (Passed hs-tier1 - hs-tier4 testing and x86_32 build.) > > Otherwise, I'll handle it as a separate PR. That is the kind of change I was unsure should be made - if the semantics are always strict does it make sense to keep the version with strict in their name instead? But if the compiler team prefer to get rid of them I'm happy to pull in your patch. Thanks! David > ------------- > > Marked as reviewed by vlivanov (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From david.holmes at oracle.com Mon May 17 06:38:38 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 16:38:38 +1000 Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: <36e73a59-6772-a34a-86e5-068fe4ac609f@oracle.com> Message-ID: On 17/05/2021 3:40 pm, Thomas Stuefe wrote: > On Mon, 17 May 2021 00:56:13 GMT, David Holmes wrote: > >>> Hi Thomas, >>> This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :( >> >> Misread the problem. I thought the logging was an issue even when >> disabled. With it enabled I don't really care if it causes a lag in the >> handshake. To me this is not an issue. >> > > To me it is, since logging should disturb the timing behaviour of the VM as little as possible. Especially if the fix is that simple. I'd argue more strongly if it weren't for the fact that when we create a thread suspended we can only get logging after the "handshake" with the creator. So this mimics that case. David > ..Thomas > >> David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4042 > From iklam at openjdk.java.net Mon May 17 06:39:39 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 17 May 2021 06:39:39 GMT Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means [v6] In-Reply-To: References: Message-ID: <2agrxKYkQHuDhDZMSFwrM1K9-Q5tyG5TzGc_5p1VVsc=.28ca3bde-925c-48a7-ac68-b14d1bfa3508@github.com> On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: >> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >> >> Tests: >> - [x] tier1, 2 > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > declare has_old_class_version as a const method > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 15/05/2021 7:14 am, Ioi Lam wrote: > > > On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: > > > > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > > > Tests: > > > > - [x] tier1, 2 > > > > > > > > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > > declare has_old_class_version as a const method > > > > > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > > Hi Calvin, > > > On 12/05/2021 2:23 am, Calvin Cheung wrote: > > > > Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. > > > > > > > > > I guess you missed the fact that I had changed the bug synopsis. Why not > > > call this needs_old_verifier (or something like that) so that the exact > > > meaning of this method is more clear? > > > > > > needs_old_verifier isn't clear, either. `has_old_class_version(K)` returns true if K is "new" but one of K's supertypes is "old". K itself does not "need the old verifier". > > and k itself does not "have an old class version" so the current method > is even more misleadingly named! > > How about inverting it and having has_post_Java_6_hierarchy: return true > if k and all its supertypes are post-Java-6 classfile version. It's unclear whether hierarchy refers to the super types, subtypes, or both. > Seriously we must be able to name this method in a more meaningful way. :( Trying to describe what the function does in a short and meaningful name is not always possible. In this case, I think it's better to say what the function intends to do. `InstanceKlass::can_be_verified_at_dumptime()` will probably suffice. It's unlikely that this function will be used for any other purpose. ------------- PR: https://git.openjdk.java.net/jdk/pull/3983 From david.holmes at oracle.com Mon May 17 06:55:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 16:55:43 +1000 Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v3] In-Reply-To: References: Message-ID: <776b6104-67cb-4aa7-6081-9323ed769346@oracle.com> Thanks Thomas! David On 17/05/2021 3:44 pm, Thomas Stuefe wrote: > On Mon, 17 May 2021 02:27:10 GMT, David Holmes wrote: > >>> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >>> >>> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >>> >>> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >>> >>> Tested tiers 1-3 for good measure. >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify API changes based on Gerard's suggestion. > > Looks still good. > > ..Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4006 > From david.holmes at oracle.com Mon May 17 07:04:59 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 17:04:59 +1000 Subject: RFR: 8266822: Rename MetaspaceShared::is_old_class to be more explicit about what "old" means [v6] In-Reply-To: <2agrxKYkQHuDhDZMSFwrM1K9-Q5tyG5TzGc_5p1VVsc=.28ca3bde-925c-48a7-ac68-b14d1bfa3508@github.com> References: <2agrxKYkQHuDhDZMSFwrM1K9-Q5tyG5TzGc_5p1VVsc=.28ca3bde-925c-48a7-ac68-b14d1bfa3508@github.com> Message-ID: <7510652d-eea1-66ac-1aae-44e78e2da1c6@oracle.com> On 17/05/2021 4:39 pm, Ioi Lam wrote: > On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: > >>> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >>> >>> Tests: >>> - [x] tier1, 2 >> >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> declare has_old_class_version as a const method > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ >> >> On 15/05/2021 7:14 am, Ioi Lam wrote: >> >>> On Tue, 11 May 2021 22:47:44 GMT, Calvin Cheung wrote: >>>>> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >>>>> Tests: >>>>> - [x] tier1, 2 >>>> >>>> >>>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >>>> declare has_old_class_version as a const method >>> >>> >>>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ >>>> Hi Calvin, >>>> On 12/05/2021 2:23 am, Calvin Cheung wrote: >>>>> Please review this simple patch for renaming the function from `MetaspaceShared::is_old_class` to `MetaspaceShared::has_old_class_version`. Also added some comment to the function. >>>> >>>> >>>> I guess you missed the fact that I had changed the bug synopsis. Why not >>>> call this needs_old_verifier (or something like that) so that the exact >>>> meaning of this method is more clear? >>> >>> >>> needs_old_verifier isn't clear, either. `has_old_class_version(K)` returns true if K is "new" but one of K's supertypes is "old". K itself does not "need the old verifier". >> >> and k itself does not "have an old class version" so the current method >> is even more misleadingly named! >> >> How about inverting it and having has_post_Java_6_hierarchy: return true >> if k and all its supertypes are post-Java-6 classfile version. > > It's unclear whether hierarchy refers to the super types, subtypes, or both. The hierarchy from a given class is always up. >> Seriously we must be able to name this method in a more meaningful way. :( > > Trying to describe what the function does in a short and meaningful name is not always possible. > > In this case, I think it's better to say what the function intends to do. `InstanceKlass::can_be_verified_at_dumptime()` will probably suffice. It's unlikely that this function will be used for any other purpose. That works for me. Thanks, David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3983 > From rehn at openjdk.java.net Mon May 17 07:05:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:05:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> On Thu, 13 May 2021 05:22:51 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > >> 46: // The rules are: >> 47: // - We must never safepoint poll if raw monitor is owned. >> 48: // - We may safepoint poll before it is owned and after it has been released. > > I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: JavaThread: -lock RM LOOP { -wait RM -do stufff with data from VM thread } -unlock RM The user do not call into the VM/Java. VM Thread: -safepoint -lock RM -notify RM -unlock RM If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. But he would also deadlock if he used a pthread mutex because that code would be buggy. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Mon May 17 07:23:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 17:23:26 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> References: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> Message-ID: <87e79d33-1c7f-3d0f-edfb-3376d3c267d9@oracle.com> On 17/05/2021 5:05 pm, Robbin Ehn wrote: > On Thu, 13 May 2021 05:22:51 GMT, David Holmes wrote: > >>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fixes for Dan >> >> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: >> >>> 46: // The rules are: >>> 47: // - We must never safepoint poll if raw monitor is owned. >>> 48: // - We may safepoint poll before it is owned and after it has been released. >> >> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. > > This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: > JavaThread: > -lock RM > LOOP { > -wait RM > -do stufff with data from VM thread > } > -unlock RM > > The user do not call into the VM/Java. > > VM Thread: > -safepoint > -lock RM > -notify RM > -unlock RM > > If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. > > If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. Only if the VMThread executes code that uses the same RM - which should be a rare occurrence. David ----- > But he would also deadlock if he used a pthread mutex because that code would be buggy. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From rehn at openjdk.java.net Mon May 17 07:24:40 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:24:40 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 05:24:03 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96: > >> 94: protected: >> 95: JvmtiRawMonitor* _rm; >> 96: bool _rm_exit; > > If this signifies the monitor exited then please name it `_rm_exited`. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Mon May 17 07:05:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 07:05:51 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:13:14 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Change option and method name > > src/hotspot/share/runtime/safepointMechanism.inline.hpp line 67: > >> 65: } >> 66: >> 67: void SafepointMechanism::process_if_requested(JavaThread* thread) { > > Looking at the stack from the crash: > > > V [libjvm.dylib+0x8c1060] _ZN21MarkActivationClosure12do_code_blobEP8CodeBlob+0x3c > V [libjvm.dylib+0x8fea78] _ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x84 > V [libjvm.dylib+0x401100] _ZN14HandshakeState18process_self_innerEv+0x18c > V [libjvm.dylib+0x400f60] _ZN14HandshakeState15process_by_selfEv+0x48 > V [libjvm.dylib+0x832690] _ZN18SafepointMechanism25process_if_requested_slowEP10JavaThread+0x54 > V [libjvm.dylib+0x8fe4b8] _ZN10JavaThread44check_safepoint_and_suspend_for_native_transEPS_+0x24 > V [libjvm.dylib+0x92395c] _ZN19ProgrammableInvoker13invoke_nativeEPFvPhES0_P10JavaThread+0x118 > V [libjvm.dylib+0x923aa8] PI_invokeNative+0x104 > J 2565 jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(JJ)V jdk.incubator.foreign at 17-ea (0 bytes) @ 0x00000001189eeed0 > > > why aren't we adding the assertion closer to the frame that crashed, where we need it, like for example: > > `HandshakeState::process_self_inner()` If we push the check too low we only do it when we hit this code and there is something to process, but we want to detect when we reach this code in the wrong state even if we wouldn't actually crash at this time due to there not being an active poll. David ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From dholmes at openjdk.java.net Mon May 17 07:05:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 07:05:50 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:18:19 GMT, Anton Kozlov wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Change option and method name Changes looks good to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3920 From rehn at openjdk.java.net Mon May 17 07:45:39 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:45:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 05:46:59 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: > >> 275: class ThreadBlockInVM { >> 276: InFlightMutexRelease _ifmr; >> 277: ThreadBlockInVMPreprocess _tbivmpp; > > Why delegate to the TBIVMPP instead of extending it? I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 07:58:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:58:23 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 09:50:56 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47: > >> 45: JavaThread* current_java_thread = JavaThread::current(); >> 46: assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm"); >> 47: { > > Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well. Fixed > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410: > >> 408: ret = simple_wait(self, millis); >> 409: _waiters--; >> 410: _recursions = save; > > The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again. Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > >> 50: // native for all operations. However we need to honor a suspend request, not >> 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend >> 52: // request// and reading the interrupt flag must be done from VM state > > `s/request///request/` ?? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 07:58:24 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:58:24 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <165oJPFEipZ7u6iG0buImc-eTxwyPf-EOkKn3GpzlJg=.13f86155-ddf6-4ccb-aee9-9df674081520@github.com> On Mon, 17 May 2021 01:36:05 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: >> >>> 384: _waiters++; >>> 385: ret = simple_wait(self, millis); >>> 386: _waiters--; >> >> We don't own the monitor yet so you cannot modify `_waiters` here. >> Any reason you moved and duplicated this block? > > Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait. > > This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly. Actually the field is unused. The _entry_list is the list of waiters, which is the only thing we really care about. If there was a reader of _waiter reading it without lock can only be used as some kind of hint. If you have lock you can just check _entry_list. I duplicated it because otherwise I would need two branchse on if (self->is_Java_thread()) which creates more complicated code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 08:09:09 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 08:09:09 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <3j6Egl0cd7pkHjWQfOTr65Kpk_7OmNLfo8xYK_AfWjM=.a97f7d87-06b6-46bc-b30d-75f12391f96f@github.com> On Thu, 13 May 2021 05:57:55 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/objectMonitor.cpp line 435: > >> 433: EnterI(current); >> 434: } >> 435: if (!eos.om_op_done()) { > > I find this API too generic. I'd much rather see: > > if (!eos.exited()) { > assert ... > break; > } Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _om_op_done; > > Please rename to _exited - we know what the "op" is so no need to use generic terminology. Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 313: > >> 311: ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {} >> 312: void operator()(JavaThread* current); >> 313: bool om_op_done() { return _om_op_done; } > > please rename to exited() Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 315: > >> 313: bool om_op_done() { return _om_op_done; } >> 314: }; >> 315: class ClearSuccOnSuspend : public ExitOnSuspend { > > I don't see why there is any relationship between these two. You don't clear-succ and exit. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stuefe at openjdk.java.net Mon May 17 08:19:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 08:19:38 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:22:39 GMT, Ioi Lam wrote: >> Hi Ioi, >> >> thank you for looking at this. >> >>> Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. >>> >>> In the future, if we want to both CDS and >4G CCS, we can revisit this. >> >> I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms. >> >> Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot. >> >> If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g. >> >> Cheers, Thomas > >> Hi Ioi, >> >> thank you for looking at this. >> >> > Since we already have an assert to check that the range is less than 4G, can?t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well. >> > In the future, if we want to both CDS and >4G CCS, we can revisit this. >> >> I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms. >> >> Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot. >> >> If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g. >> >> Cheers, Thomas > > My reasoning is -- this is platform independent code. If this patch works for aarch64, it must also work for other platforms. Conversely, If it doesn't work for any other platform, why do we believe it would work on aarch64? > > Since we test other platforms much more than aarch64, I think the best way to ensure that the patch works is to also turn it on for all platforms. > > JDK 17 repo branch happens next month, but we still have a couple of months afterwards for bug fixes. I think we have enough time to handle any problems that may happen. > > Lilliput is not going to happen for a while, and we can handle it when the time comes. (It's not like the existing hard-coded shift of 3 is going to be much more compatible with Liliput than 0). @iklam Ioi, are you fine with this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From rehn at openjdk.java.net Mon May 17 08:29:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 08:29:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <5z8gIP9ALINo5U1RdyqJiZQFb1BlYA69zR-8PUQsa0Q=.76c28c76-7eda-4acd-b744-cb39c018bec0@github.com> On Thu, 13 May 2021 05:27:42 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207: > >> 205: assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state"); >> 206: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); >> 207: _thread->set_thread_state(_thread_in_native); > > After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes? I looked over the transitions this fall, I don't know but there are some of these oddities. One problem is the some of the generic named transitions RAII are actually supposed to be used only at certain places and some optimizations have been added. E.g. in this case someone have figured out that we can remove make_walkable(), but as a generic rule when going to a safe state (blocked/native) you should call make_walkable. My guess is that calling make_walkable on every JNI/JVM TI call was expensive on Solaris, so someone optimized that. Now I'm unsure if that is actually true (I my feeling is no, because we could accidentally call Java if we hit e.g. class loading or something). And the optimization is no longer valid, make_walkable() is light weight on current hardware AFAIK. I updated to what I see as a correct transition to an safe state without any short cuts. I also notice I missed an assert from the previous code. Re-running all test, since these kinds of changes should not be taken lightly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From shade at openjdk.java.net Mon May 17 09:07:17 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 09:07:17 GMT Subject: RFR: 8267229: Split runtime/Metaspace/elastic test configurations for better scalability Message-ID: JDK-8251158 added runtime/Metaspace/elastic tests that run in hotspot:tier1. Unfortunately, those tests are quite long, and they contribute to long tail in hotspot:tier1 on larger machines. We can split the test by configuration for better scalability. Additional testing: - [x] affected tests on Linux x86_64, fastdebug/release - [x] hotspot:tier1 on Linux x86_64, fastdebug Times before: # runtime/Metaspace/elastic real 3m49.412s user 9m27.347s sys 0m30.982s # hotspot:tier1 real 9m26.916s user 273m45.575s sys 24m49.788s Times after: # runtime/Metaspace/elastic real 1m14.261s user 9m51.823s sys 0m31.092s # hotspot:tier1 real 7m7.153s user 268m49.231s sys 25m53.377s ------------- Commit messages: - Whitespace fixes - 8267229: Split runtime/Metaspace/elastic test configurations for better scalability Changes: https://git.openjdk.java.net/jdk/pull/4047/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4047&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267229 Stats: 192 lines in 2 files changed: 174 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4047.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4047/head:pull/4047 PR: https://git.openjdk.java.net/jdk/pull/4047 From akozlov at openjdk.java.net Mon May 17 09:17:41 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 17 May 2021 09:17:41 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 07:01:52 GMT, David Holmes wrote: >> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 67: >> >>> 65: } >>> 66: >>> 67: void SafepointMechanism::process_if_requested(JavaThread* thread) { >> >> Looking at the stack from the crash: >> >> >> V [libjvm.dylib+0x8c1060] _ZN21MarkActivationClosure12do_code_blobEP8CodeBlob+0x3c >> V [libjvm.dylib+0x8fea78] _ZN10JavaThread11nmethods_doEP15CodeBlobClosure+0x84 >> V [libjvm.dylib+0x401100] _ZN14HandshakeState18process_self_innerEv+0x18c >> V [libjvm.dylib+0x400f60] _ZN14HandshakeState15process_by_selfEv+0x48 >> V [libjvm.dylib+0x832690] _ZN18SafepointMechanism25process_if_requested_slowEP10JavaThread+0x54 >> V [libjvm.dylib+0x8fe4b8] _ZN10JavaThread44check_safepoint_and_suspend_for_native_transEPS_+0x24 >> V [libjvm.dylib+0x92395c] _ZN19ProgrammableInvoker13invoke_nativeEPFvPhES0_P10JavaThread+0x118 >> V [libjvm.dylib+0x923aa8] PI_invokeNative+0x104 >> J 2565 jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(JJ)V jdk.incubator.foreign at 17-ea (0 bytes) @ 0x00000001189eeed0 >> >> >> why aren't we adding the assertion closer to the frame that crashed, where we need it, like for example: >> >> `HandshakeState::process_self_inner()` > > If we push the check too low we only do it when we hit this code and there is something to process, but we want to detect when we reach this code in the wrong state even if we wouldn't actually crash at this time due to there not being an active poll. > > David David, thanks, this is exactly how it meant to be. The crash happens when a thread is synchronized for MarkActivationClosure. Having the check in the HandshakeState::process_self_inner would catch the wrong state when a thread is synchronized also for something else. The patch catches the wrong state if a thread polls synchronization, it does not need to actually synchronize to trigger the check. So we'll catch more. ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From rrich at openjdk.java.net Mon May 17 09:35:46 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 17 May 2021 09:35:46 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395: > 393: ThreadBlockInVMPreprocess tbivmp(jt, eos); > 394: simple_enter(jt); > 395: _recursions = save; I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stuefe at openjdk.java.net Mon May 17 10:00:44 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 10:00:44 GMT Subject: RFR: 8267229: Split runtime/Metaspace/elastic test configurations for better scalability In-Reply-To: References: Message-ID: On Mon, 17 May 2021 08:46:42 GMT, Aleksey Shipilev wrote: > JDK-8251158 added runtime/Metaspace/elastic tests that run in hotspot:tier1. Unfortunately, those tests are quite long, and they contribute to long tail in hotspot:tier1 on larger machines. We can split the test by configuration for better scalability. > > Attention @tstuefe. > > Additional testing: > - [x] affected tests on Linux x86_64, fastdebug/release > - [x] hotspot:tier1 on Linux x86_64, fastdebug > > Times before: > > > # runtime/Metaspace/elastic > > real 3m49.412s > user 9m27.347s > sys 0m30.982s > > # hotspot:tier1 > > real 9m26.916s > user 273m45.575s > sys 24m49.788s > > > Times after: > > > # runtime/Metaspace/elastic > > real 1m14.261s > user 9m51.823s > sys 0m31.092s > > # hotspot:tier1 > > real 7m7.153s > user 268m49.231s > sys 25m53.377s Very good, thanks for doing this. BTW I plan to move part of them out of tier1 after JDK17, but atm would like to leave them in tier1 since Metaspace gets still worked on and JEP 387 is still fresh. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4047 From rehn at openjdk.java.net Mon May 17 11:24:42 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 11:24:42 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:32:23 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395: > >> 393: ThreadBlockInVMPreprocess tbivmp(jt, eos); >> 394: simple_enter(jt); >> 395: _recursions = save; > > I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stefank at openjdk.java.net Mon May 17 11:25:39 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 17 May 2021 11:25:39 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 16:00:09 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > add missing include Changes requested by stefank (Reviewer). src/hotspot/share/classfile/classLoaderData.hpp line 331: > 329: > 330: unsigned identity_hash() const { > 331: return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From rschmelter at openjdk.java.net Mon May 17 11:50:43 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Mon, 17 May 2021 11:50:43 GMT Subject: Integrated: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. This pull request has now been integrated. Changeset: a29612ea Author: Ralf Schmelter URL: https://git.openjdk.java.net/jdk/commit/a29612ea9998a8e45f25add7ae30bfbc62ce3756 Stats: 51 lines in 3 files changed: 15 ins; 24 del; 12 mod 8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException Reviewed-by: rrich, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From hseigel at openjdk.java.net Mon May 17 12:49:56 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 17 May 2021 12:49:56 GMT Subject: RFR: 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java Message-ID: Please review this small change to remove unused LoadClass.java and remove comments that reference it. Mach5 tiers 1-3 were run to sanity check that LoadClass.java is not used. Thanks, Harold ------------- Commit messages: - 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java Changes: https://git.openjdk.java.net/jdk/pull/4059/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4059&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267166 Stats: 126 lines in 4 files changed: 0 ins; 126 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4059/head:pull/4059 PR: https://git.openjdk.java.net/jdk/pull/4059 From coleenp at openjdk.java.net Mon May 17 12:55:41 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 17 May 2021 12:55:41 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:36:40 GMT, Vladimir Ivanov wrote: >> Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. >> >> Found 3 occurrences: >> - `Dependencies::find_finalizable_subclass()` >> - `reinitialize_vtable_of()` >> - `VM_RedefineClasses::increment_class_counter()` >> >> Testing: >> - [x] hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JFR good also! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3995 From rehn at openjdk.java.net Mon May 17 13:02:07 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 13:02:07 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be Message-ID: Please consider this change-set which address the issue on hand. I identified two problems: - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. Fixed by leaving the handshakee being processed in queue until completed. And remove looping, since if ever the queue is empty the handshakee may processed. If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. Fixed by adding a loadload. I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. (real reprod ~1/400 with increased test time) If we are updating the poll there should not be an active handshaker. The above fixed the issue. But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). Passes stressing relevant test on aarch64 and t1-7. Thanks, Robbin ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/3973/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266557 Stats: 152 lines in 6 files changed: 81 ins; 42 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/3973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973 PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 17 14:30:48 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 14:30:48 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: References: Message-ID: On Fri, 14 May 2021 08:01:12 GMT, Yude Lin wrote: > Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. > > An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond > > I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. We can just remove this: if (i != 0 && thread->is_Java_thread()) { JavaThread* jt = thread->as_Java_thread(); if (jt->thread_state() == _thread_in_vm) { // Since this JavaThread has looped at least once and is _thread_in_vm, // we honor any pending blocking request. ThreadBlockInVM tbivm(jt); } } Under some wired circumstances it can prolong TTS. But it was me that found it. Reverting it would get any complains from anyone else. (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From patricio.chilano.mateo at oracle.com Mon May 17 14:57:13 2021 From: patricio.chilano.mateo at oracle.com (patricio.chilano.mateo at oracle.com) Date: Mon, 17 May 2021 11:57:13 -0300 Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: References: Message-ID: <4e21e7c1-6eee-bcee-ebaf-769a5360a052@oracle.com> On 5/15/21 5:04 AM, Yude Lin wrote: > On Fri, 14 May 2021 19:49:10 GMT, Patricio Chilano Mateo wrote: > >> We cannot do a return here because a safepoint could be already in progress after transitioning out of the blocked state. The handshake would then execute concurrently with the safepoint operation which is not allowed. > I didn't get this part. Being able to return means that we are already in another enclosing SafepointMechanism::process_if_requested_slow(). This enclosing SafepointMechanism::process_if_requested_slow() should make sure we are processing the handshake safely, right? The issue is that inside the handshake closure you would transition to the blocked state in ThreadBlockInVM(), which allows a safepoint to proceed. If in ~ThreadBlockInVM() we don't stop for the safepoint and just return in SafepointMechanism::process_if_requested_slow() then now you would have a safepoint and handshake executing at the same time. If we want to keep the ThreadBlockInVM in GenerateOopMap::do_interpretation() we need to either avoid calling it while inside a handshake closure (by moving the check further up as you try to do in your other version), or we move the check further down to after honoring the safepoint in SafepointSynchronize::block() (as with the old flag we used to have). The latter implies answering the question of whether it is even safe to allow safepoints in the first place and then resume the handshake, which again I don't think it is. Avoid polling is a straightforward solution for this issue and goes in line with the NoSafepointVerifier checks that we use in handshake.cpp. Or as Robbin pointed out we could back out 8262443 altogether.? : ) > It's indeed release build. But fastdebug build miraculously runs without any hang or crash. Maybe it took a different path. > > While I was figuring out why the debug build won't crash. I found that the condition `i != 0` in do_interpretation (if I understand correctly, it's just a spin count) could be hiding the reentrance problem. If I make the change > > diff --git a/src/hotspot/share/oops/generateOopMap.cpp b/src/hotspot/share/oops/generateOopMap.cpp > index 06ae6b0dbaf..8048aa92fc6 100644 > --- a/src/hotspot/share/oops/generateOopMap.cpp > +++ b/src/hotspot/share/oops/generateOopMap.cpp > @@ -911,7 +911,7 @@ void GenerateOopMap::do_interpretation(Thread* thread) > { > int i = 0; > do { > - if (i != 0 && thread->is_Java_thread()) { > + if (thread->is_Java_thread()) { > JavaThread* jt = thread->as_Java_thread(); > if (jt->thread_state() == _thread_in_vm) { > // Since this JavaThread has looped at least once and is _thread_in_vm, > > > > I get > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/yude.lyd/jdk-master/src/hotspot/share/runtime/mutex.cpp:407), pid=122250, tid=123348 > # assert(false) failed: Attempting to acquire lock tty_lock/3 out of order with lock stack_watermark_lock/2 -- possible deadlock > # > # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-adhoc.yudelyd.jdk-master) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 17-internal+0-adhoc.yudelyd.jdk-master, mixed mode, sharing, compressed oops, compressed class ptrs, shenandoah gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x1485e50] Mutex::check_rank(Thread*)+0x120 > # > # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # Yes, this is a similar issue. We cannot poll for safepoints while processing a watermark also. The rank check is just a secondary issue of trying to grab tty_lock while crashing. So backing out 8262443 would solve that too. Thanks, Patricio > --------------- S U M M A R Y ------------ > > Command Line: -Xmx24g -Xms24g -XX:ParallelGCThreads=16 -XX:+UseShenandoahGC -XX:-TieredCompilation -Xlog:gc*=debug,handshake=trace:file=510s.log:tid:filesize=200m SPECjvm2008.jar -ict -coe -i 5 derby > > XXXX, Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz, 96 cores, 503G, XXXX > Time: Sat May 15 15:32:28 2021 CST elapsed time: 101.087584 seconds (0d 0h 1m 41s) > > --------------- T H R E A D --------------- > > Current thread (0x00007f5ca802ecc0): JavaThread "BenchmarkThread derby 51" [_thread_in_vm, id=123348, stack(0x00007f5b8b4f5000,0x00007f5b8b5f6000)] > > Stack: [0x00007f5b8b4f5000,0x00007f5b8b5f6000], sp=0x00007f5b8b5f1f20, free space=1011k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1485e50] Mutex::check_rank(Thread*)+0x120 > V [libjvm.so+0x14867f1] Mutex::lock_without_safepoint_check(Thread*)+0x51 > V [libjvm.so+0x1541090] defaultStream::hold(long)+0xa0 > V [libjvm.so+0x154124a] defaultStream::write(char const*, unsigned long)+0x2a > V [libjvm.so+0x153dc30] outputStream::do_vsnprintf_and_write_with_automatic_buffer(char const*, __va_list_tag*, bool)+0xf0 > V [libjvm.so+0x153e97f] outputStream::print_cr(char const*, ...)+0x1bf > V [libjvm.so+0x1981063] JavaThread::check_possible_safepoint()+0x63 > V [libjvm.so+0xd2f838] GenerateOopMap::do_interpretation(Thread*)+0x238 > V [libjvm.so+0xd2fe0e] GenerateOopMap::compute_map(Thread*)+0x3ae > V [libjvm.so+0x150d243] OopMapForCacheEntry::compute_map(Thread*)+0x163 > V [libjvm.so+0x150eef5] OopMapCacheEntry::fill(methodHandle const&, int)+0xf5 > V [libjvm.so+0x150fa40] OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x60 > V [libjvm.so+0x141d876] Method::mask_for(int, InterpreterOopMap*)+0x96 > V [libjvm.so+0xbd6381] frame::oops_interpreted_do(OopClosure*, RegisterMap const*, bool) const+0x4c1 > V [libjvm.so+0x185073e] StackWatermarkFramesIterator::process_one(void*)+0x20e > V [libjvm.so+0x18515f8] StackWatermark::process_one()+0x88 > V [libjvm.so+0x18526e9] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0x89 > V [libjvm.so+0xbd98ca] frame::sender(RegisterMap*) const+0x7a > V [libjvm.so+0x167f988] check_compiled_frame(JavaThread*)+0x88 > V [libjvm.so+0x168397a] OptoRuntime::new_instance_C(Klass*, JavaThread*)+0xfa > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4028 From iklam at openjdk.java.net Mon May 17 15:38:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 17 May 2021 15:38:44 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken [v2] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 05:44:06 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. >> >> I manually tested that this fix works. Patch includes a repro case. >> >> Cheers, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > zero shift for cds=on/dump on all platforms LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3968 From gziemski at openjdk.java.net Mon May 17 16:08:54 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 17 May 2021 16:08:54 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v3] In-Reply-To: References: Message-ID: <7es4rirCM42_Ww0X41jPNnr326_I43yRt6_9ucsS1T8=.987393bc-5d60-4af4-b0af-3b853ad560fc@github.com> On Mon, 17 May 2021 02:27:10 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Simplify API changes based on Gerard's suggestion. Looks good, thanks! ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/4006 From gziemski at openjdk.java.net Mon May 17 16:11:39 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 17 May 2021 16:11:39 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:18:19 GMT, Anton Kozlov wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Change option and method name Looks good, thanks! ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/3920 From gziemski at openjdk.java.net Mon May 17 16:16:45 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 17 May 2021 16:16:45 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:14:45 GMT, Anton Kozlov wrote: >> If we push the check too low we only do it when we hit this code and there is something to process, but we want to detect when we reach this code in the wrong state even if we wouldn't actually crash at this time due to there not being an active poll. >> >> David > > David, thanks, this is exactly how it meant to be. > > The crash happens when a thread is synchronized for MarkActivationClosure. Having the check in the HandshakeState::process_self_inner would catch the wrong state when a thread is synchronized also for something else. The patch catches the wrong state if a thread polls synchronization, it does not need to actually synchronize to trigger the check. So we'll catch more. Thank you for the explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From stuefe at openjdk.java.net Mon May 17 16:17:56 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 16:17:56 GMT Subject: Integrated: 8265705: aarch64: KlassDecodeMovk mode broken In-Reply-To: References: Message-ID: On Tue, 11 May 2021 07:49:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. > > I manually tested that this fix works. Patch includes a repro case. > > Cheers, Thomas This pull request has now been integrated. Changeset: 3c010a7c Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/3c010a7c7e64706ee6124d6e9ef69a5f3cf0d1ba Stats: 44 lines in 2 files changed: 26 ins; 0 del; 18 mod 8265705: aarch64: KlassDecodeMovk mode broken Reviewed-by: aph, iklam, ngasson ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From stuefe at openjdk.java.net Mon May 17 16:19:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 17 May 2021 16:19:01 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out Message-ID: This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. Thanks, Thomas ------------- Commit messages: - fix test - preparation, copy smaps, smaps replacement feed Changes: https://git.openjdk.java.net/jdk/pull/4064/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267155 Stats: 87 lines in 1 file changed: 61 ins; 2 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From gziemski at openjdk.java.net Mon May 17 16:24:52 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 17 May 2021 16:24:52 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 14:45:42 GMT, Gerard Ziemski wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. >> >> We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > use the existing executable flag to indicate whether we want to commit exec memory or not @theRealAph Could you please sign off on this change if you are OK with my change incorporating your feedback? ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From gziemski at openjdk.java.net Mon May 17 16:36:03 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 17 May 2021 16:36:03 GMT Subject: RFR: 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:38:12 GMT, Harold Seigel wrote: > Please review this small change to remove unused LoadClass.java and remove comments that reference it. Mach5 tiers 1-3 were run to sanity check that LoadClass.java is not used. > > Thanks, Harold I grepped `test/hotspot` for **LoadClass** and I think that you got them all, thanks! ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/4059 From shade at openjdk.java.net Mon May 17 16:42:50 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 16:42:50 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out In-Reply-To: References: Message-ID: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> On Mon, 17 May 2021 16:09:32 GMT, Thomas Stuefe wrote: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Cursory review follows. The alternative would be to disable this on kernels < 3.8? See the commits from my last PR: https://github.com/openjdk/jdk/pull/3415/files/c7a6136cedb827260f43ecc850a8910492cfefcc..1df37de73ed6615db565aeafe76edf30dcee108d test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 107: > 105: private static Path copySmaps() throws Exception { > 106: Path p1 = Paths.get("/proc/self/smaps"); > 107: Path p2 = Paths.get("smaps-copy-" + ProcessHandle.current().pid() + "-" + run++ + ".txt"); Suggestion: Path p2 = Paths.get("smaps-copy-" + ProcessHandle.current().pid() + "-" + (run++) + ".txt"); test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 109: > 107: Path p2 = Paths.get("smaps-copy-" + ProcessHandle.current().pid() + "-" + run++ + ".txt"); > 108: Files.copy(p1, p2, StandardCopyOption.REPLACE_EXISTING); > 109: System.out.println("Copied " + p1.getFileName() + " to " + p2.getFileName() + "..."); `Path.toString()` is defined, I think, so... Suggestion: System.out.println("Copied " + p1 + " to " + p2 + "..."); test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 136: > 134: Pattern sectionStartPat = Pattern.compile("^([a-f0-9]+)-([a-f0-9]+) [\\-rwpsx]{4}.*"); > 135: Pattern kernelPageSizePat = Pattern.compile("^KernelPageSize:\\s*(\\d*) kB"); > 136: Pattern vmFlagsPat = Pattern.compile("^VmFlags: ([\\w\\? ]*)"); Suggestion: static final Pattern SECTION_START_PATT = Pattern.compile("^([a-f0-9]+)-([a-f0-9]+) [\-rwpsx]{4}.*"); static final Pattern KERNEL_PAGESIZE_PATT = Pattern.compile("^KernelPageSize:\\s*(\\d*) kB"); static final Pattern VMFLAGS_PATT = Pattern.compile("^VmFlags: ([\\w\? ]*)"); test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 139: > 137: int lineno = 0; > 138: void reset() { > 139: start = end = ps = vmFlags = null; Suggestion: start = null; end = null; ps = null; vmFlags = null; test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 152: > 150: > 151: void eatNext(String line) { > 152: debug("" + lineno++ + " " + line); Suggestion: debug("" + (lineno++) + " " + line); test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 158: > 156: start = matSectionStart.group(1); > 157: end = matSectionStart.group(2); > 158: ps = vmFlags = null; Suggestion: ps = null; vmFlags = null; test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 180: > 178: SmapsParser parser2 = new SmapsParser(); > 179: Files.lines(smapsFileToParse).forEach(parser2::eatNext); > 180: parser2.finish(); Suggestion: SmapsParser parser = new SmapsParser(); Files.lines(smapsFileToParse).forEach(parser::eatNext); parser.finish(); ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From shade at openjdk.java.net Mon May 17 16:42:51 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 16:42:51 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out In-Reply-To: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> References: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> Message-ID: On Mon, 17 May 2021 16:28:57 GMT, Aleksey Shipilev wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 136: > >> 134: Pattern sectionStartPat = Pattern.compile("^([a-f0-9]+)-([a-f0-9]+) [\\-rwpsx]{4}.*"); >> 135: Pattern kernelPageSizePat = Pattern.compile("^KernelPageSize:\\s*(\\d*) kB"); >> 136: Pattern vmFlagsPat = Pattern.compile("^VmFlags: ([\\w\\? ]*)"); > > Suggestion: > > static final Pattern SECTION_START_PATT = Pattern.compile("^([a-f0-9]+)-([a-f0-9]+) [\-rwpsx]{4}.*"); > static final Pattern KERNEL_PAGESIZE_PATT = Pattern.compile("^KernelPageSize:\\s*(\\d*) kB"); > static final Pattern VMFLAGS_PATT = Pattern.compile("^VmFlags: ([\\w\? ]*)"); ...and probably move it before instance fields block. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From iklam at openjdk.java.net Mon May 17 17:13:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 17 May 2021 17:13:40 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 06:00:33 GMT, Yi Yang wrote: >> While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > ID2KlassTable* instead of ID2KlassTable * LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4007 From minqi at openjdk.java.net Mon May 17 17:29:40 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 17 May 2021 17:29:40 GMT Subject: RFR: 8265705: aarch64: KlassDecodeMovk mode broken [v2] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 05:44:06 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have a review for this aarch64-specific fix? Details see JBS issue and code comment. >> >> I manually tested that this fix works. Patch includes a repro case. >> >> Cheers, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > zero shift for cds=on/dump on all platforms src/hotspot/share/oops/compressedOops.cpp line 222: > 220: > 221: base = addr; > 222: Could you fix the comments at line 212, the words used seem not correct --- to the end of sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/3968 From iklam at openjdk.java.net Mon May 17 17:55:46 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 17 May 2021 17:55:46 GMT Subject: RFR: 8267191 avoid repeated should be excluded Message-ID: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. Skipping org/eclipse/osgi/util/NLS: Signed JAR Skipping org/eclipse/osgi/util/NLS: Signed JAR Skipping org/eclipse/osgi/util/NLS: Signed JAR BTW, to make the code a little easier to read, I also changed warn_excluded(k, "Failed verification"); return true; to return warn_excluded(k, "Failed verification"); ------------- Commit messages: - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into 8267191-avoid-repeated-should_be_excluded - 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls Changes: https://git.openjdk.java.net/jdk/pull/4070/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4070&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267191 Stats: 78 lines in 2 files changed: 28 ins; 22 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/4070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4070/head:pull/4070 PR: https://git.openjdk.java.net/jdk/pull/4070 From akozlov at openjdk.java.net Mon May 17 19:19:52 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 17 May 2021 19:19:52 GMT Subject: RFR: 8266742: Check W^X state on possible safepoint [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:18:19 GMT, Anton Kozlov wrote: >> Hi, >> >> Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). >> >> This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. >> >> I still owe a complete W^X approach description. Hope this patch does not depend much on that. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Change option and method name Thank you for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From akozlov at openjdk.java.net Mon May 17 19:19:53 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 17 May 2021 19:19:53 GMT Subject: Integrated: 8266742: Check W^X state on possible safepoint In-Reply-To: References: Message-ID: On Fri, 7 May 2021 15:37:12 GMT, Anton Kozlov wrote: > Hi, > > Please review a check for W^X mode at safepoint. As described in the bug, this explicit check aims to catch the wrong W^X mode that may lead to a crash (such crashes are rather intermittent). > > This check helped to verify the fix for https://bugs.openjdk.java.net/browse/JDK-8265292 and should help to discover similar issues. It is disabled by default to avoid unexpected failures in the regular use, but eventually it should be turned on unconditionally. > > I still owe a complete W^X approach description. Hope this patch does not depend much on that. This pull request has now been integrated. Changeset: 3b11d811 Author: Anton Kozlov URL: https://git.openjdk.java.net/jdk/commit/3b11d811a274ae1d91fdcc5f01bcd5d159f0543b Stats: 25 lines in 3 files changed: 18 ins; 0 del; 7 mod 8266742: Check W^X state on possible safepoint Reviewed-by: dholmes, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/3920 From ioi.lam at oracle.com Mon May 17 21:13:20 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 17 May 2021 14:13:20 -0700 Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: Correcting the title of the PR: JDK-8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls On 5/17/21 10:55 AM, Ioi Lam wrote: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); > > ------------- > > Commit messages: > - fixed merge > - Merge branch 'master' of https://github.com/openjdk/jdk into 8267191-avoid-repeated-should_be_excluded > - 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls > > Changes: https://git.openjdk.java.net/jdk/pull/4070/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4070&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8267191 > Stats: 78 lines in 2 files changed: 28 ins; 22 del; 28 mod > Patch: https://git.openjdk.java.net/jdk/pull/4070.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4070/head:pull/4070 > > PR: https://git.openjdk.java.net/jdk/pull/4070 From kvn at openjdk.java.net Mon May 17 22:27:02 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 22:27:02 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: Message-ID: On Wed, 12 May 2021 05:33:14 GMT, David Holmes wrote: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From kvn at openjdk.java.net Mon May 17 22:27:02 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 22:27:02 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: Message-ID: On Fri, 14 May 2021 16:29:41 GMT, Vladimir Ivanov wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > Overall, it looks very good. > Thanks for taking care of compiler part, David. > > I think it makes sense to remove lir_div_strictfp and lir_mul_strictfp in C1 as well: > https://github.com/openjdk/jdk/pull/4027 > > Feel free to incorporate the patch into the current PR if you agree with the change. > (Passed hs-tier1 - hs-tier4 testing and x86_32 build.) > > Otherwise, I'll handle it as a separate PR. @iwanowww I agree with your suggestion but lets do it in separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From dholmes at openjdk.java.net Mon May 17 22:42:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 22:42:48 GMT Subject: RFR: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report [v3] In-Reply-To: References: Message-ID: <4aAXtXJuOHPfJm4J2x2gfSCw-h5iHjWJfyHzLzlY1Uk=.32edac0c-5ecb-48d9-9492-21619d1a7814@github.com> On Mon, 17 May 2021 02:27:10 GMT, David Holmes wrote: >> A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. >> >> VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. >> >> Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. >> >> Tested tiers 1-3 for good measure. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Simplify API changes based on Gerard's suggestion. Thanks Gerard! ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From dholmes at openjdk.java.net Mon May 17 22:42:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 22:42:49 GMT Subject: Integrated: 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report In-Reply-To: References: Message-ID: On Thu, 13 May 2021 02:14:43 GMT, David Holmes wrote: > A simple fix to add a new VMErrorType (OOM_JAVA_HEAP_FATAL) to indicate we've requested a Java OOM error to be fatal. A new overload of report_fatal is provided to allow this to be passed through. > > VMError has an existing notion of "should_report_bug" but that encompasses more than just printing the bug submission URL, so I added a new specific check for that. > > Checked hs_err files before and after with the fix, from the CrashOnOutOfMemoryError test. > > Tested tiers 1-3 for good measure. > > Thanks, > David This pull request has now been integrated. Changeset: cd1c17c0 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/cd1c17c0a6416a8d16cf2035f3e97dba95b6b8af Stats: 16 lines in 4 files changed: 7 ins; 1 del; 8 mod 8266404: Fatal error report generated with -XX:+CrashOnOutOfMemoryError should not contain suggestion to submit a bug report Reviewed-by: stuefe, kevinw, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/4006 From jiefu at openjdk.java.net Mon May 17 23:37:01 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 17 May 2021 23:37:01 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 Message-ID: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Hi all, vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 ------------- Commit messages: - 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 Changes: https://git.openjdk.java.net/jdk/pull/4076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4076&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267293 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4076/head:pull/4076 PR: https://git.openjdk.java.net/jdk/pull/4076 From ddong at openjdk.java.net Tue May 18 02:24:41 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 18 May 2021 02:24:41 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 11:22:49 GMT, Stefan Karlsson wrote: >> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: >> >> add missing include > > src/hotspot/share/classfile/classLoaderData.hpp line 331: > >> 329: >> 330: unsigned identity_hash() const { >> 331: return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); > > LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out. Hi, I think it makes sense. How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From yyang at openjdk.java.net Tue May 18 02:28:48 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 18 May 2021 02:28:48 GMT Subject: RFR: 8267089: Use typedef KVHashtable for ID2KlassTable [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 06:00:33 GMT, Yi Yang wrote: >> While backporting some stuff to jdk11, I noticed main functionalities of ID2KlassTable have been removed afterJDK-8213587, it seems that we can use a simple typedef KVHashtable instead. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > ID2KlassTable* instead of ID2KlassTable * Thank Xin and Ioi for taking time to look at this PR! ------------- PR: https://git.openjdk.java.net/jdk/pull/4007 From david.holmes at oracle.com Tue May 18 03:08:06 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 May 2021 13:08:06 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: Message-ID: Hi Vladimir, Thanks for the review. On 18/05/2021 8:27 am, Vladimir Kozlov wrote: > On Fri, 14 May 2021 16:29:41 GMT, Vladimir Ivanov wrote: > >>> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >>> >>> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> Overall, it looks very good. >> Thanks for taking care of compiler part, David. >> >> I think it makes sense to remove lir_div_strictfp and lir_mul_strictfp in C1 as well: >> https://github.com/openjdk/jdk/pull/4027 >> >> Feel free to incorporate the patch into the current PR if you agree with the change. >> (Passed hs-tier1 - hs-tier4 testing and x86_32 build.) >> >> Otherwise, I'll handle it as a separate PR. > > @iwanowww I agree with your suggestion but lets do it in separate RFE. I can pull it into this change as there is no rush to integrate this given I need to wait for JEP 306 to be targeted. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From stuefe at openjdk.java.net Tue May 18 04:07:22 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 04:07:22 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v2] In-Reply-To: References: Message-ID: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with seven additional commits since the last revision: - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java renamings Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Brackets around ++ Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Use Path.toString Co-authored-by: Aleksey Shipil?v ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4064/files - new: https://git.openjdk.java.net/jdk/pull/4064/files/16507093..3ee7409f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=00-01 Stats: 16 lines in 1 file changed: 4 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Tue May 18 04:07:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 04:07:23 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v2] In-Reply-To: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> References: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> Message-ID: On Mon, 17 May 2021 16:39:59 GMT, Aleksey Shipilev wrote: > Cursory review follows. > > The alternative would be to disable this on kernels < 3.8? See the commits from my last PR: > https://github.com/openjdk/jdk/pull/3415/files/c7a6136cedb827260f43ecc850a8910492cfefcc..1df37de73ed6615db565aeafe76edf30dcee108d Hmm, I like faster tests even on new kernels, therefore I would like to use this parser instead of the regex. Also think it makes the test more readable and robust, but that may be just me. E.g. you don't rely on order of entry in smaps. But we could do both, of course. Lets ask @kstefanj , its his test. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From dholmes at openjdk.java.net Tue May 18 04:26:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 04:26:00 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: lir_div_strictfp and lir_mul_strictfp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/683da141..c0c35a77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=00-01 Stats: 116 lines in 20 files changed: 9 ins; 74 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From dholmes at openjdk.java.net Tue May 18 04:36:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 04:36:41 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 16:29:41 GMT, Vladimir Ivanov wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> lir_div_strictfp and lir_mul_strictfp > > Overall, it looks very good. > Thanks for taking care of compiler part, David. > > I think it makes sense to remove lir_div_strictfp and lir_mul_strictfp in C1 as well: > https://github.com/openjdk/jdk/pull/4027 > > Feel free to incorporate the patch into the current PR if you agree with the change. > (Passed hs-tier1 - hs-tier4 testing and x86_32 build.) > > Otherwise, I'll handle it as a separate PR. @iwanowww and @vnkozlov I have merged @iwanowww 's changes with this PR and am re-testing. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From stuefe at openjdk.java.net Tue May 18 04:42:00 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 04:42:00 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v3] In-Reply-To: References: Message-ID: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - heap size -> 128m - fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4064/files - new: https://git.openjdk.java.net/jdk/pull/4064/files/3ee7409f..6032d415 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=01-02 Stats: 24 lines in 1 file changed: 3 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Tue May 18 04:42:01 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 04:42:01 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:07:22 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with seven additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > renamings > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Brackets around ++ > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Use Path.toString > > Co-authored-by: Aleksey Shipil?v I also reduced the heap size of the tests to 128m, which makes it more likely for the explicit huge page allocations to actually get large pages, especially when running in parallel with other tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Tue May 18 05:15:48 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 05:15:48 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 In-Reply-To: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Mon, 17 May 2021 23:28:43 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. > > We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 Hi Jie, You can safely get by with less. A very safe bet for all platforms would be: - 256m heap - 8m MaxMetaspaceSize The latter could be probably reduced more (the smaller metaspace, the faster the test comes to conclusion), down to 6m or 4m. On my machine 4m works for both 64 and 32bit. But 8m is probably safe on all platforms. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From shade at openjdk.java.net Tue May 18 06:42:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 06:42:43 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:42:00 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - heap size -> 128m > - fixes Yes, I don't mind this going in. I was just pointing the way you could fix the test on <3.8 kernels either here on in separate PR. test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 101: > 99: private static LinkedList ranges = new LinkedList<>(); > 100: private static boolean debug = false; > 101: private static int run = 0; Suggestion: private static boolean debug; private static int run; test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 132: > 130: static final Pattern SECTION_START_PATT = Pattern.compile("^([a-f0-9]+)-([a-f0-9]+) [\\-rwpsx]{4}.*"); > 131: static final Pattern KERNEL_PAGESIZE_PATT = Pattern.compile("^KernelPageSize:\\s*(\\d*) kB"); > 132: static final Pattern VMFLAGS_PATT = Pattern.compile("^VmFlags: ([\\w\\? ]*)"); String start; Suggestion: static final Pattern VMFLAGS_PATT = Pattern.compile("^VmFlags: ([\\w\? ]*)"); String start; test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 136: > 134: String ps; > 135: String vmFlags; > 136: int lineno = 0; Suggestion: int lineno; test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 161: > 159: debug = true; > 160: } else { > 161: debug = false; Let's keep the code shape with explicit initialization here? Also drop the init at the field declaration? test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 162: > 160: end = matSectionStart.group(2); > 161: ps = null; > 162: vmFlags = null; I can see that `Range` code handles `vmFlags = null` specifically. Does it handle `ps == null`? I cannot see it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From shade at openjdk.java.net Tue May 18 06:43:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 06:43:41 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 In-Reply-To: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Mon, 17 May 2021 23:28:43 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. > > We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 Yeah, this works on my machines: diff --git a/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java b/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java index 0d5f1a1626f..980c9303f04 100644 --- a/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java +++ b/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java @@ -36,7 +36,7 @@ * @build vm.mlvm.anonloader.stress.oome.metaspace.Test * @run driver vm.mlvm.share.IndifiedClassesBuilder * - * @run main/othervm -XX:-UseGCOverheadLimit -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m vm.mlvm.anonloader.stress.oome.metaspace.Test + * @run main/othervm -Xmx256m -XX:-UseGCOverheadLimit -XX:MaxMetaspaceSize=8m vm.mlvm.anonloader.stress.oome.metaspace.Test */ package vm.mlvm.anonloader.stress.oome.metaspace; ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From dholmes at openjdk.java.net Tue May 18 06:48:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 06:48:41 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: <0EpJCBNs6TfxOUDAGKJlrfzwR1dRIbvLzeShgHpnZIg=.c88a5693-7018-457b-bdbb-c9bd68fe105a@github.com> On Mon, 17 May 2021 17:39:32 GMT, Ioi Lam wrote: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); Hi Ioi, These changes seem fine. A couple of nits below. Thanks, David src/hotspot/share/classfile/systemDictionaryShared.cpp line 1409: > 1407: if (k->is_hidden() && !is_registered_lambda_proxy_class(k)) { > 1408: ResourceMark rm; > 1409: log_debug(cds)("Skipping %s: %s", k->name()->as_C_string(), "Hidden class"); You don't need to feed "Hidden class" to a %s. src/hotspot/share/classfile/systemDictionaryShared.cpp line 1416: > 1414: if (super != NULL && check_for_exclusion(super, NULL)) { > 1415: ResourceMark rm; > 1416: log_warning(cds)("Skipping %s: super class %s is excluded @%p", k->name()->as_C_string(), super->name()->as_C_string(), super); Pretty sure we still don't/can't use %p in shared code, but should be INTPTR_FORMAT and use p2i(super) src/hotspot/share/classfile/systemDictionaryShared.cpp line 1425: > 1423: InstanceKlass* intf = interfaces->at(i); > 1424: if (check_for_exclusion(intf, NULL)) { > 1425: log_warning(cds)("Skipping %s: interface %s is excluded @%p", k->name()->as_C_string(), intf->name()->as_C_string(), intf); Ditto on %p ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4070 From jiefu at openjdk.java.net Tue May 18 06:50:12 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 06:50:12 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. > > We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: -XX:MaxMetaspaceSize=8m ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4076/files - new: https://git.openjdk.java.net/jdk/pull/4076/files/0838bac9..2e618c17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4076&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4076&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4076.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4076/head:pull/4076 PR: https://git.openjdk.java.net/jdk/pull/4076 From jiefu at openjdk.java.net Tue May 18 06:50:13 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 06:50:13 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 05:12:33 GMT, Thomas Stuefe wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> -XX:MaxMetaspaceSize=8m > > Hi Jie, > > You can safely get by with less. A very safe bet for all platforms would be: > > - 256m heap > - 8m MaxMetaspaceSize > > The latter could be probably reduced more (the smaller metaspace, the faster the test comes to conclusion), down to 6m or 4m. On my machine 4m works for both 64 and 32bit. But 8m is probably safe on all platforms. > > Cheers, Thomas Thanks @tstuefe and @shipilev . The test time has been reduced from 41.8s to 34.8s . And it passed on all our x86 platforms. Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From stuefe at openjdk.java.net Tue May 18 06:53:19 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 06:53:19 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Co-authored-by: Aleksey Shipil?v - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java oops Co-authored-by: Aleksey Shipil?v ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4064/files - new: https://git.openjdk.java.net/jdk/pull/4064/files/6032d415..d5785cbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Tue May 18 06:53:23 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 06:53:23 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: <7Jl1-mz-Henu2B0E2M53XtjJqhCdGLF8HZ_8ZEPbdJA=.ea92a240-bc2a-442d-a3e9-2e69f0dba7ca@github.com> On Tue, 18 May 2021 06:37:44 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java >> >> Co-authored-by: Aleksey Shipil?v >> - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java >> >> oops >> >> Co-authored-by: Aleksey Shipil?v > > test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 161: > >> 159: debug = true; >> 160: } else { >> 161: debug = false; > > Let's keep the code shape with explicit initialization here? Also drop the init at the field declaration? I did this to quickly turn on debug by changing the default value above. I could not figure out how to add command line parameters to the test on the jtreg command line and did not feel like modifying every single at-run. But I have no strong emotions, if you prefer I can reinstate the old behaviour. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From shade at openjdk.java.net Tue May 18 06:53:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 06:53:24 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: <7Jl1-mz-Henu2B0E2M53XtjJqhCdGLF8HZ_8ZEPbdJA=.ea92a240-bc2a-442d-a3e9-2e69f0dba7ca@github.com> References: <7Jl1-mz-Henu2B0E2M53XtjJqhCdGLF8HZ_8ZEPbdJA=.ea92a240-bc2a-442d-a3e9-2e69f0dba7ca@github.com> Message-ID: On Tue, 18 May 2021 06:48:38 GMT, Thomas Stuefe wrote: >> test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 161: >> >>> 159: debug = true; >>> 160: } else { >>> 161: debug = false; >> >> Let's keep the code shape with explicit initialization here? Also drop the init at the field declaration? > > I did this to quickly turn on debug by changing the default value above. I could not figure out how to add command line parameters to the test on the jtreg command line and did not feel like modifying every single at-run. But I have no strong emotions, if you prefer I can reinstate the old behaviour. Yeah, let's keep it the old way. You can change the `debug = true` right here next time, I think. IIRC, that's what I did before. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From david.holmes at oracle.com Tue May 18 07:26:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 May 2021 17:26:02 +1000 Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: Hi Robbin, On 17/05/2021 11:02 pm, Robbin Ehn wrote: > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > Fixed by leaving the handshakee being processed in queue until completed. Sorry but I'm not seeing how leaving or removing the op from the queue impacts things here. Which thread is reading the queue and seeing a wrong value? Thanks, David ----- > And remove looping, since if ever the queue is empty the handshakee may processed. > If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. > But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) > > Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. > > - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. > Fixed by adding a loadload. > > I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. > (real reprod ~1/400 with increased test time) > If we are updating the poll there should not be an active handshaker. > The above fixed the issue. > But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. > > Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). > > Passes stressing relevant test on aarch64 and t1-7. > > Thanks, Robbin > > ------------- > > Commit messages: > - Fix > > Changes: https://git.openjdk.java.net/jdk/pull/3973/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8266557 > Stats: 152 lines in 6 files changed: 81 ins; 42 del; 29 mod > Patch: https://git.openjdk.java.net/jdk/pull/3973.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973 > > PR: https://git.openjdk.java.net/jdk/pull/3973 > From dholmes at openjdk.java.net Tue May 18 07:37:46 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 07:37:46 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v6] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 04:45:11 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Restore previous is_strict cdoe in method.hpp. > - Merge branch 'master' into 8266530 > - Make methods strict on IA32. > - Merge branch 'master' into 8266530 > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Hi Joe, In classfileparser.cpp should this: else if ((flags & JVM_ACC_STATIC) == JVM_ACC_STATIC) { flags &= JVM_ACC_STATIC | JVM_ACC_STRICT; also be conditional on !major_gte_17? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From shade at openjdk.java.net Tue May 18 08:11:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 08:11:43 GMT Subject: Integrated: 8267229: Split runtime/Metaspace/elastic test configurations for better scalability In-Reply-To: References: Message-ID: <_xIpPOYQuuK3CexhND9xh3xehzIwglrRX7geuuLNAcU=.b64342b6-7136-4ec3-8dfe-dfe0ad99cf31@github.com> On Mon, 17 May 2021 08:46:42 GMT, Aleksey Shipilev wrote: > JDK-8251158 added runtime/Metaspace/elastic tests that run in hotspot:tier1. Unfortunately, those tests are quite long, and they contribute to long tail in hotspot:tier1 on larger machines. We can split the test by configuration for better scalability. > > Attention @tstuefe. > > Additional testing: > - [x] affected tests on Linux x86_64, fastdebug/release > - [x] hotspot:tier1 on Linux x86_64, fastdebug > > Times before: > > > # runtime/Metaspace/elastic > > real 3m49.412s > user 9m27.347s > sys 0m30.982s > > # hotspot:tier1 > > real 9m26.916s > user 273m45.575s > sys 24m49.788s > > > Times after: > > > # runtime/Metaspace/elastic > > real 1m14.261s > user 9m51.823s > sys 0m31.092s > > # hotspot:tier1 > > real 7m7.153s > user 268m49.231s > sys 25m53.377s This pull request has now been integrated. Changeset: f6c28911 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f6c2891118b06631db796c863638e10cf62ff45b Stats: 192 lines in 2 files changed: 174 ins; 0 del; 18 mod 8267229: Split runtime/Metaspace/elastic test configurations for better scalability Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/4047 From rehn at openjdk.java.net Tue May 18 08:25:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 18 May 2021 08:25:41 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Tue, 11 May 2021 11:59:23 GMT, Robbin Ehn wrote: > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > Fixed by leaving the handshakee being processed in queue until completed. > And remove looping, since if ever the queue is empty the handshakee may processed. > If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. > But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) > > Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. > > - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. > Fixed by adding a loadload. > > I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. > (real reprod ~1/400 with increased test time) > If we are updating the poll there should not be an active handshaker. > The above fixed the issue. > But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. > > Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). > > Passes stressing relevant test on aarch64 and t1-7. > > Thanks, Robbin > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > Hi Robbin, > > On 17/05/2021 11:02 pm, Robbin Ehn wrote: > > > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > > Fixed by leaving the handshakee being processed in queue until completed. > > Sorry but I'm not seeing how leaving or removing the op from the queue > impacts things here. Which thread is reading the queue and seeing a > wrong value? When poll is armed the handshakee must go to slow path and lock the HandshakeState lock if: - 1: There is handshake operation to be processed - 2: Some-else is in the middle of processing a handshake operation for this handshakee By having having a non-empty queue if 1 or 2 is true, the handshakee can just ask if there is a non-empty queue. If so go to slow path and grab the HandshakeState lock. Now 1 is checked with queue head and 2 is checked with is_locked(). But since the thread locking, storing _owner, can do this unordered, it may store the owner field after it have read our thread state, e.g. blocked. What we do in three different scenarios are: Handshaker adds an operation: store queue store poll Handshaker processing do: store _owner (lock) load queue load poll load thread state Handshakee polling path do: store state load poll load owner load queue ############################################ With the un-ordered characteristics of _owner field, it looks like it could play out like this: Handshakee: state blocked Handshaker A processor: add: store queue OP Z Handshaker B processor: processes OP Z and store queue => NULL Handshaker A processor: add: store poll Handshaker A processor: LOCK HandshakeState lock (_owner is still NULL) Handshaker C processor: add: store queue OP X Handshaker A processor: load queue (sees X) Handshaker A processor: load poll (armed) Handshaker A processor: load thread state // OK blocked Handshakee T target : store state // unsafe Handshakee T target : load poll // armed Handshakee T target : load owner // NULL Handshaker A processor: store _owner (non-NULL) // re-ordered here !! Handshaker A processor: store queue (NULL) Handshakee T target : load queue // NULL Handshakee T target : disarm // ERROR !!!! > > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From stefank at openjdk.java.net Tue May 18 08:39:41 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 18 May 2021 08:39:41 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 02:21:29 GMT, Denghui Dong wrote: >> src/hotspot/share/classfile/classLoaderData.hpp line 331: >> >>> 329: >>> 330: unsigned identity_hash() const { >>> 331: return (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3)); >> >> LogMinObjAlignmentInBytes describes the alignment requirements for Java objects. I know that some other places in the VM reuse this for generating hash codes, but I don't think that's appropriate, and they should be cleaned out. > > Hi, > I think it makes sense. > How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch? I created a CR for this: https://bugs.openjdk.java.net/browse/JDK-8267303 but I still think that this usage should not be introduced in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From aph at openjdk.java.net Tue May 18 09:11:43 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 18 May 2021 09:11:43 GMT Subject: RFR: 8262952: [macos_aarch64] os::commit_memory failure [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 14:45:42 GMT, Gerard Ziemski wrote: >> On x86_64 macOS the following sequence works just fine: >> >> attempt_reserve_memory_at(executable=false) >> commit_memory(executable=true) >> >> however, on aarch64 macOS it fails. >> >> We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > use the existing executable flag to indicate whether we want to commit exec memory or not Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From github.com+16811675+linade at openjdk.java.net Tue May 18 09:28:38 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Tue, 18 May 2021 09:28:38 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: References: Message-ID: <3jFXzMxaxGPL_Tbc-PbJJHG6wH0FLqm_Po4_DNw0p0c=.19a7a073-9db9-4635-b310-05c331dd280a@github.com> On Mon, 17 May 2021 14:25:49 GMT, Robbin Ehn wrote: > We can just remove this: > > if (i != 0 && thread->is_Java_thread()) { > JavaThread* jt = thread->as_Java_thread(); > if (jt->thread_state() == _thread_in_vm) { > // Since this JavaThread has looped at least once and is _thread_in_vm, > // we honor any pending blocking request. > ThreadBlockInVM tbivm(jt); > } > } > > Under some wired circumstances it can prolong TTS. > But it was me that found it. Reverting it wouldn't get any complains from anyone else. > > (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) In that case this is a solution I can get behind. > The issue is that inside the handshake closure you would transition to > the blocked state in ThreadBlockInVM(), which allows a safepoint to > proceed. If in ~ThreadBlockInVM() we don't stop for the safepoint and > just return in SafepointMechanism::process_if_requested_slow() then now > you would have a safepoint and handshake executing at the same time. Ah I see, there I was thinking a thread is only considered in safepoint by VM Thread when it's blocked in SafepointMechanism::process, but it actually happen when transitioned to the _thread_blocked state. Thanks for pointing it out! ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From shade at openjdk.java.net Tue May 18 09:46:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 09:46:42 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 06:50:12 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. >> >> We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 >> [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > -XX:MaxMetaspaceSize=8m Seems like GHA is barfing up due to infrastructure issues. Please re-start the jobs, once current run finishes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From shade at openjdk.java.net Tue May 18 09:50:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 09:50:41 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 06:50:12 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. >> >> We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 >> [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > -XX:MaxMetaspaceSize=8m "/test" command does not work. GHA start automatically on PR updates and/or with manual trigger: https://github.com/DamonFool/jdk/actions/workflows/submit.yml ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From sjohanss at openjdk.java.net Tue May 18 09:54:41 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 09:54:41 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: <-EqB4kQKk2vDycsCy6eqL-vabOXQ3phx5NcWpvIhwjY=.b704bb2a-a163-484d-9749-5eac8f90fe6d@github.com> Message-ID: On Tue, 18 May 2021 04:03:22 GMT, Thomas Stuefe wrote: > > Cursory review follows. > > The alternative would be to disable this on kernels < 3.8? See the commits from my last PR: > > https://github.com/openjdk/jdk/pull/3415/files/c7a6136cedb827260f43ecc850a8910492cfefcc..1df37de73ed6615db565aeafe76edf30dcee108d > > Hmm, I like faster tests even on new kernels, therefore I would like to use this parser instead of the regex. Also think it makes the test more readable and robust, but that may be just me. E.g. you don't rely on order of entry in smaps. > > But we could do both, of course. Lets ask @kstefanj , its his test. I'm of course biased since I wrote the test. That said, I don't consider this _my_ test, so I won't object to changing it. Personally I prefer the regex-parsing is clearer since it "parses" one segment at a time in the smaps file. I think if we go with this new parser, it would be nice to add some comments clarifying the steps. An alternative would be to have different regular expressions depending on the kernel version or first check if vmFlags are present and choose the correct expression. This would of course not help if this kind of parsing is still very slow on some systems. I like that you do a copy of smaps before parsing, that crossed my mind as well, to help debugging. Regarding smaller heap sizes. I don't see a problem if some of the test VMs fail getting large pages, since it tests that we still log the correct thing. Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR). ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From jiefu at openjdk.java.net Tue May 18 10:47:39 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 10:47:39 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 09:47:51 GMT, Aleksey Shipilev wrote: > "/test" command does not work. GHA start automatically on PR updates and/or with manual trigger: https://github.com/DamonFool/jdk/actions/workflows/submit.yml Got it. Thanks for your help. @shipilev ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From stuefe at openjdk.java.net Tue May 18 10:57:50 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 10:57:50 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 06:53:19 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > oops > > Co-authored-by: Aleksey Shipil?v Hi Stefan, > > > Cursory review follows. > > > The alternative would be to disable this on kernels < 3.8? See the commits from my last PR: > > > https://github.com/openjdk/jdk/pull/3415/files/c7a6136cedb827260f43ecc850a8910492cfefcc..1df37de73ed6615db565aeafe76edf30dcee108d > > > > > > Hmm, I like faster tests even on new kernels, therefore I would like to use this parser instead of the regex. Also think it makes the test more readable and robust, but that may be just me. E.g. you don't rely on order of entry in smaps. > > But we could do both, of course. Lets ask @kstefanj , its his test. > > I'm of course biased since I wrote the test. That said, I don't consider this _my_ test, so I won't object to changing it. > Sorry, I meant no offence. I think this test is really useful, since I want to be able to rely on the page sizes in the traces and not have to countercheck the smaps file. That's why I put work in it instead of just disabling it. What I meant was do you consider testing correct tracing of *explicit* huge pages important enough on semi-old kernels before 3.8? If not, we can modify the test to skip older kernels completely, otherwise just the detect-THP-part? > Personally I prefer the regex-parsing is clearer since it "parses" one segment at a time in the smaps file. Unfortunately its not so easy since its smaps sections don't have a clear ending. I played around yesterday and gave up after a while. I also find regex code beyond a certain complexity really work intensive and difficult to debug. The original regexp was also too loose, I think, since `(\\w+)-(\\w+)` - unanchored to the start of a line - matches the permissions if those contain dashes. And theoretically, you could accidentally match across secions, were one to miss a flag. > I think if we go with this new parser, it would be nice to add some comments clarifying the steps. Okay, I could do that. > > An alternative would be to have different regular expressions depending on the kernel version or first check if vmFlags are present and choose the correct expression. This would of course not help if this kind of parsing is still very slow on some systems. I think its just more vulnerable against unknown or future smaps variants. E.g. relying on a specific order of entries. > > I like that you do a copy of smaps before parsing, that crossed my mind as well, to help debugging. Regarding smaller heap sizes. I don't see a problem if some of the test VMs fail getting large pages, since it tests that we still log the correct thing. I prefer the "explicit-large-pages" test to really run a VM with explicit large pages. Otherwise we test with small pages, which would be the same as with the other tests. > > Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR). This test has been a bit of whack-a-mole; I am interested in a stable test which covers the important cases. E.g. I tried to find a clear definition of AnonHugePages but beyond that it requires the kernel to be compiled with THP I did not find any indication that this is synonymous with THP, or under which circumstances it is set, or whats its relationship to KernelPageSize is. I also suspect it is kernel-version-dependent like the other properties. Frankly am interested in this test for testing trace of explicit huge pages correctly, not so much THP. Since this is what most of our customers use. THP have a bad rep here because they used to come with problems. And since hugetlbfs has gotten easier to use (eg with vm.nr_overcommit_hugepages) I usually use that instead of TPH. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From shade at openjdk.java.net Tue May 18 11:05:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 11:05:42 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v3] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 06:40:08 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - heap size -> 128m >> - fixes > > Yes, I don't mind this going in. I was just pointing the way you could fix the test on <3.8 kernels either here on in separate PR. > > Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR). > > This test has been a bit of whack-a-mole; I am interested in a stable test which covers the important cases. E.g. I tried to find a clear definition of AnonHugePages but beyond that it requires the kernel to be compiled with THP I did not find any indication that this is synonymous with THP, or under which circumstances it is set, or whats its relationship to KernelPageSize is. https://www.kernel.org/doc/Documentation/vm/transhuge.txt: "The number of anonymous transparent huge pages currently used by the system is available by reading the AnonHugePages field in /proc/meminfo. To identify what applications are using anonymous transparent huge pages, it is necessary to read /proc/PID/smaps and count the AnonHugePages fields for each mapping." But as we found earlier, this does not work because for many VM structures we are only _reserving_ the memory, while AnonHugePages > 0 only when we actually _commit_ stuff. So AnonHugePages is a lost cause, IMO. The only reliable way to test THP seems to be VmFlags. If VmFlags are not available, that the end. We can only stop testing for THP at that point... ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Tue May 18 11:23:41 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 11:23:41 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:54:30 GMT, Thomas Stuefe wrote: > > > > I'm of course biased since I wrote the test. That said, I don't consider this _my_ test, so I won't object to changing it. > > Sorry, I meant no offence. I think this test is really useful, since I want to be able to rely on the page sizes in the traces and not have to countercheck the smaps file. That's why I put work in it instead of just disabling it. > None taken ?? > What I meant was do you consider testing correct tracing of _explicit_ huge pages important enough on semi-old kernels before 3.8? If not, we can modify the test to skip older kernels completely, otherwise just the detect-THP-part? > I'm good with keeping testing even on older kernels, since you run into this it obviously has some value testing it. > > Personally I prefer the regex-parsing is clearer since it "parses" one segment at a time in the smaps file. > > Unfortunately its not so easy since its smaps sections don't have a clear ending. I played around yesterday and gave up after a while. I also find regex code beyond a certain complexity really work intensive and difficult to debug. > > The original regexp was also too loose, I think, since `(\\w+)-(\\w+)` - unanchored to the start of a line - matches the permissions if those contain dashes. And theoretically, you could accidentally match across secions, were one to miss a flag. > True, the reg-ex approach has problems and as you say, future changes to the format might be more brittle with a reg-ex. > > I think if we go with this new parser, it would be nice to add some comments clarifying the steps. > > Okay, I could do that. > ?? > > An alternative would be to have different regular expressions depending on the kernel version or first check if vmFlags are present and choose the correct expression. This would of course not help if this kind of parsing is still very slow on some systems. > > I think its just more vulnerable against unknown or future smaps variants. E.g. relying on a specific order of entries. > > > I like that you do a copy of smaps before parsing, that crossed my mind as well, to help debugging. Regarding smaller heap sizes. I don't see a problem if some of the test VMs fail getting large pages, since it tests that we still log the correct thing. > > I prefer the "explicit-large-pages" test to really run a VM with explicit large pages. Otherwise we test with small pages, which would be the same as with the other tests. > What I meant was that we can get the scenario where some reservations are small and some large, but that can still happen even with a smaller heap size, so I'm good with changing it. > > Just wanted to share my thoughts before doing a proper review. I'm happy to review this patch if we decide to go with this new parser. If we do that I also think we should look at enabling parsing of `AnonHugePages` for the case where vmFlags are not present (similar to @shipilev approach in the last PR). > > This test has been a bit of whack-a-mole; I am interested in a stable test which covers the important cases. E.g. I tried to find a clear definition of AnonHugePages but beyond that it requires the kernel to be compiled with THP I did not find any indication that this is synonymous with THP, or under which circumstances it is set, or whats its relationship to KernelPageSize is. I also suspect it is kernel-version-dependent like the other properties. > > Frankly am interested in this test for testing trace of explicit huge pages correctly, not so much THP. Since this is what most of our customers use. THP have a bad rep here because they used to come with problems. And since hugetlbfs has gotten easier to use (eg with vm.nr_overcommit_hugepages) I usually use that instead of TPH. > Yeah, the THP part might have been over-shooting it a bit, but I was quite happy when I found the `vmFlags` and never considered the older kernels. I'm good with disabling THP testing when vmFlags are not present. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Tue May 18 11:23:42 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 11:23:42 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v3] In-Reply-To: References: Message-ID: <8Q21CWy3IOfAS-ZJw2MKUz58ceT95I4lkQR90sjMApw=.51ae508d-4189-488c-9d48-f4f0e0a2ce55@github.com> On Tue, 18 May 2021 11:02:47 GMT, Aleksey Shipilev wrote: > But as we found earlier, this does not work because for many VM structures we are only _reserving_ the memory, while AnonHugePages > 0 only when we actually _commit_ stuff. So AnonHugePages is a lost cause, IMO. The only reliable way to test THP seems to be VmFlags. If VmFlags are not available, that the end. We can only stop testing for THP at that point... Correct, forgot about that =) Let's just skip testing of THP if vmFlags are missing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Tue May 18 11:33:45 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 11:33:45 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: <3pcTH8qVTVL-uRATf-YB1ICmk9HuLABiXfMjb4iaAnM=.afaab179-3c1d-4bd6-9266-d2d794c5c6bf@github.com> On Tue, 18 May 2021 06:53:19 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > oops > > Co-authored-by: Aleksey Shipil?v Added some initial comments to the code. test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 109: > 107: Path p2 = Paths.get("smaps-copy-" + ProcessHandle.current().pid() + "-" + (run++) + ".txt"); > 108: Files.copy(p1, p2, StandardCopyOption.REPLACE_EXISTING); > 109: System.out.println("Copied " + p1 + " to " + p2 + "..."); Consider using `debug(...)` for this and the other `System.out.println(..)`calls. test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 119: > 117: // will generate a match. > 118: private static void parseSmaps() throws Exception { > 119: // We can override the smaps file to parse to pass in a pre-fetched one Please update the above comment to match the new parsing. test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 311: > 309: // * ht - Meaning the range is mapped using explicit huge pages. > 310: // * hg - Meaning the range is madvised huge. > 311: if (vmFlags != null) { Update comment to explain the smaps sometimes don't have `vmFlags`. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4064 From coleenp at openjdk.java.net Tue May 18 11:37:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 18 May 2021 11:37:42 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: On Mon, 17 May 2021 17:39:32 GMT, Ioi Lam wrote: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4070 From ddong at openjdk.java.net Tue May 18 11:39:04 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 18 May 2021 11:39:04 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9] In-Reply-To: References: Message-ID: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: remote LogMinObjAlignmentInBytes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3901/files - new: https://git.openjdk.java.net/jdk/pull/3901/files/e9c674ca..cbed0208 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3901&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3901.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3901/head:pull/3901 PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Tue May 18 11:39:04 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 18 May 2021 11:39:04 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com> On Tue, 18 May 2021 08:37:11 GMT, Stefan Karlsson wrote: >> Hi, >> I think it makes sense. >> How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch? > > I created a CR for this: > https://bugs.openjdk.java.net/browse/JDK-8267303 > > but I still think that this usage should not be introduced in this patch. okay, removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From coleenp at openjdk.java.net Tue May 18 11:45:43 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 18 May 2021 11:45:43 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com> References: <-2ELEmM_1ZSALHkM1TJH_DYWaP69ZIsgOCXZVBsVv8Q=.b2440c88-d860-4813-a970-3f9a4c46c9e8@github.com> Message-ID: On Tue, 18 May 2021 11:33:41 GMT, Denghui Dong wrote: >> I created a CR for this: >> https://bugs.openjdk.java.net/browse/JDK-8267303 >> >> but I still think that this usage should not be introduced in this patch. > > okay, removed. This seems fine to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From sjohanss at openjdk.java.net Tue May 18 12:14:58 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 12:14:58 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages Message-ID: Please review this change to fix the large page testing on Windows. **Summary** The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. **Testing** Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. ------------- Commit messages: - Remove log-line. - 8266807: Windows os_windows-gtest broken for UseLargePages Changes: https://git.openjdk.java.net/jdk/pull/4090/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4090&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266807 Stats: 22 lines in 1 file changed: 10 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4090/head:pull/4090 PR: https://git.openjdk.java.net/jdk/pull/4090 From stuefe at openjdk.java.net Tue May 18 12:18:44 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 12:18:44 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: <1EwNW6QJ-g4k4X8fXirOApXUWJoG5Ri-Y3i_YxuefBQ=.8cb47df0-9433-4f35-9863-e5a400a68212@github.com> On Tue, 18 May 2021 06:53:19 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > oops > > Co-authored-by: Aleksey Shipil?v The more I think about this the more confused I get. In theory, THP can be enabled on a machine in a way which needs no cooperation of the VM; so whether or not we run with +UseTransparentHugePages makes no difference, pages used by the VM may be folded transparently to huge pages without our knowledge. Would on those machines the section show up as "VmFlags: hg" too? Or is this only the explicit madvice flag? Would the KernelPageSize reflect the page size set by the THP folding process (probably not since it can be multiple page sizes)? And would this "proactive folding" interfere with the recognition of hugetlb pages? In other words, could we trace out "4k" and then have a "2048k" region show up in smaps? The more I think about this, the muddier it gets. ATM I think we should just skip this test altogether for older kernels, and/or not test THP at all... not sure what to think here. I also found this piece in man proc: The "KernelPageSize" line (available since Linux 2.6.29) is the page size used by the kernel to back the virtual memory area. ..... However, one counter-example occurs on PPC64 kernels whereby a kernel using 64 kB as a base page size may still use 4 kB pages for the MMU on older processors. I propose to just skip the test on that platform. Personally I have never used large pages on a ppc machine. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Tue May 18 12:26:43 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 12:26:43 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: <1EwNW6QJ-g4k4X8fXirOApXUWJoG5Ri-Y3i_YxuefBQ=.8cb47df0-9433-4f35-9863-e5a400a68212@github.com> References: <1EwNW6QJ-g4k4X8fXirOApXUWJoG5Ri-Y3i_YxuefBQ=.8cb47df0-9433-4f35-9863-e5a400a68212@github.com> Message-ID: <3_S4L7nXBVX3zGjsxId_mx7XhWDNkGGypBXZ8YVOjl4=.64d90b98-2149-409b-9068-6ae76e3a0681@github.com> On Tue, 18 May 2021 12:15:49 GMT, Thomas Stuefe wrote: > The more I think about this the more confused I get. > I recognize that feeling ?? > In theory, THP can be enabled on a machine in a way which needs no cooperation of the VM; so whether or not we run with +UseTransparentHugePages makes no difference, pages used by the VM may be folded transparently to huge pages without our knowledge. Would on those machines the section show up as "VmFlags: hg" too? Or is this only the explicit madvice flag? Would the KernelPageSize reflect the page size set by the THP folding process (probably not since it can be multiple page sizes)? > >From what I've seen KernelPageSize is only different for the HugeTLBFS pages. Reading the doc it says this about the `hg`flag: `hg - huge page advise flag` So I also think it would only show when running with `+UseTransparentHugePages`. > And would this "proactive folding" interfere with the recognition of hugetlb pages? In other words, could we trace out "4k" and then have a "2048k" region show up in smaps? > > The more I think about this, the muddier it gets. ATM I think we should just skip this test altogether for older kernels, and/or not test THP at all... not sure what to think here. > I'm totally fine with skipping older kernel. I think the fact that we test this on newer kernels and it passes at least shows that we trace the correct thing. > I also found this piece in man proc: > > ``` > The "KernelPageSize" line (available since Linux 2.6.29) > is the page size used by the kernel to back the virtual > memory area. ..... > However, one counter-example occurs on PPC64 kernels > whereby a kernel using 64 kB as a base page > size may still use 4 kB pages for the MMU on older > processors. > ``` > > I propose to just skip the test on that platform. Personally I have never used large pages on a ppc machine. Fine with me :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From coleenp at openjdk.java.net Tue May 18 12:31:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 18 May 2021 12:31:46 GMT Subject: RFR: 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:38:12 GMT, Harold Seigel wrote: > Please review this small change to remove unused LoadClass.java and remove comments that reference it. Mach5 tiers 1-3 were run to sanity check that LoadClass.java is not used. > > Thanks, Harold Looks good plus trivial to check in. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4059 From sjohanss at openjdk.java.net Tue May 18 12:35:44 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 18 May 2021 12:35:44 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: References: Message-ID: <00rCjLEBHmC64hGpkU7j1TidO61K0eV4AgeliEelBq8=.bbaacabf-555e-4d6e-887c-8c4c51e7b4c1@github.com> On Tue, 18 May 2021 06:53:19 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > Co-authored-by: Aleksey Shipil?v > - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java > > oops > > Co-authored-by: Aleksey Shipil?v Did a quick test now with THP configured to `always` but running with `-XX:-UseLargePages -XX:-UseTransparentHugePages`. It gives me: 80000000-ffe00000 rw-p 00000000 00:00 0 Size: 2095104 kB KernelPageSize: 4 kB MMUPageSize: 4 kB ... AnonHugePages: 2095104 kB THPeligible: 1 VmFlags: rd wr mr mw me ac sd So no `hg` flag as expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From hseigel at openjdk.java.net Tue May 18 12:37:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 18 May 2021 12:37:52 GMT Subject: RFR: 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:38:12 GMT, Harold Seigel wrote: > Please review this small change to remove unused LoadClass.java and remove comments that reference it. Mach5 tiers 1-3 were run to sanity check that LoadClass.java is not used. > > Thanks, Harold Thanks Gerard and Coleen for reviewing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/4059 From hseigel at openjdk.java.net Tue May 18 12:37:52 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 18 May 2021 12:37:52 GMT Subject: Integrated: 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:38:12 GMT, Harold Seigel wrote: > Please review this small change to remove unused LoadClass.java and remove comments that reference it. Mach5 tiers 1-3 were run to sanity check that LoadClass.java is not used. > > Thanks, Harold This pull request has now been integrated. Changeset: 02507bc4 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/02507bc40d2a213768de8bacfd649e8355a2f209 Stats: 126 lines in 4 files changed: 0 ins; 126 del; 0 mod 8267166: Remove test file vmTestbase/vm/mlvm/tools/LoadClass.java Reviewed-by: gziemski, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/4059 From vlivanov at openjdk.java.net Tue May 18 12:50:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 18 May 2021 12:50:04 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses [v3] In-Reply-To: References: Message-ID: <2dW5h_12hO4zO3lnnlf-4w54KH0ImwRgYxD2U4q1uQA=.ed0cef27-9e74-4a7c-85e9-75408382a406@github.com> > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8266973.iterator - JFR - 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses ------------- Changes: https://git.openjdk.java.net/jdk/pull/3995/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3995&range=02 Stats: 101 lines in 9 files changed: 8 ins; 54 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/3995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3995/head:pull/3995 PR: https://git.openjdk.java.net/jdk/pull/3995 From vlivanov at openjdk.java.net Tue May 18 12:50:05 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 18 May 2021 12:50:05 GMT Subject: RFR: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:36:40 GMT, Vladimir Ivanov wrote: >> Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. >> >> Found 3 occurrences: >> - `Dependencies::find_finalizable_subclass()` >> - `reinitialize_vtable_of()` >> - `VM_RedefineClasses::increment_class_counter()` >> >> Testing: >> - [x] hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JFR Thanks for the reviews, Vladimir and Coleen. ------------- PR: https://git.openjdk.java.net/jdk/pull/3995 From vlivanov at openjdk.java.net Tue May 18 12:50:06 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 18 May 2021 12:50:06 GMT Subject: Integrated: 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses In-Reply-To: References: Message-ID: On Wed, 12 May 2021 13:30:09 GMT, Vladimir Ivanov wrote: > Replace ad-hoc recursion when enumerating subclasses with `ClassHierarchyIterator`. > > Found 3 occurrences: > - `Dependencies::find_finalizable_subclass()` > - `reinitialize_vtable_of()` > - `VM_RedefineClasses::increment_class_counter()` > > Testing: > - [x] hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: 9d168e25 Author: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/9d168e25d1e2e8b662dc7aa6cda7516c423cef7d Stats: 101 lines in 9 files changed: 8 ins; 54 del; 39 mod 8266973: Migrate to ClassHierarchyIterator when enumerating subclasses Reviewed-by: kvn, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3995 From stuefe at openjdk.java.net Tue May 18 14:19:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 18 May 2021 14:19:42 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: <3_S4L7nXBVX3zGjsxId_mx7XhWDNkGGypBXZ8YVOjl4=.64d90b98-2149-409b-9068-6ae76e3a0681@github.com> References: <1EwNW6QJ-g4k4X8fXirOApXUWJoG5Ri-Y3i_YxuefBQ=.8cb47df0-9433-4f35-9863-e5a400a68212@github.com> <3_S4L7nXBVX3zGjsxId_mx7XhWDNkGGypBXZ8YVOjl4=.64d90b98-2149-409b-9068-6ae76e3a0681@github.com> Message-ID: On Tue, 18 May 2021 12:23:29 GMT, Stefan Johansson wrote: > > > > I propose to just skip the test on that platform. Personally I have never used large pages on a ppc machine. > > Fine with me :) Great, at least we can rely on a set of sane information from smaps, and it will make the test simpler too. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From gziemski at openjdk.java.net Tue May 18 14:47:41 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 18 May 2021 14:47:41 GMT Subject: Integrated: 8262952: [macos_aarch64] os::commit_memory failure In-Reply-To: References: Message-ID: On Tue, 4 May 2021 19:34:18 GMT, Gerard Ziemski wrote: > On x86_64 macOS the following sequence works just fine: > > attempt_reserve_memory_at(executable=false) > commit_memory(executable=true) > > however, on aarch64 macOS it fails. > > We fix the test itself to explicitly ask for executable memory when reserving it since it later commits it as executable. This pull request has now been integrated. Changeset: fadf5804 Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/fadf58043c10e4fd98dfdb35256f5efc6d3cd366 Stats: 8 lines in 1 file changed: 2 ins; 6 del; 0 mod 8262952: [macos_aarch64] os::commit_memory failure Reviewed-by: stuefe, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/3865 From iklam at openjdk.java.net Tue May 18 18:58:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 18 May 2021 18:58:08 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls [v2] In-Reply-To: <0EpJCBNs6TfxOUDAGKJlrfzwR1dRIbvLzeShgHpnZIg=.c88a5693-7018-457b-bdbb-c9bd68fe105a@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> <0EpJCBNs6TfxOUDAGKJlrfzwR1dRIbvLzeShgHpnZIg=.c88a5693-7018-457b-bdbb-c9bd68fe105a@github.com> Message-ID: On Tue, 18 May 2021 06:42:53 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora comments > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1409: > >> 1407: if (k->is_hidden() && !is_registered_lambda_proxy_class(k)) { >> 1408: ResourceMark rm; >> 1409: log_debug(cds)("Skipping %s: %s", k->name()->as_C_string(), "Hidden class"); > > You don't need to feed "Hidden class" to a %s. Fixed. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1416: > >> 1414: if (super != NULL && check_for_exclusion(super, NULL)) { >> 1415: ResourceMark rm; >> 1416: log_warning(cds)("Skipping %s: super class %s is excluded @%p", k->name()->as_C_string(), super->name()->as_C_string(), super); > > Pretty sure we still don't/can't use %p in shared code, but should be INTPTR_FORMAT and use p2i(super) I reverted back to the original code and removed the %p. I added %p for temporary debugging only. ------------- PR: https://git.openjdk.java.net/jdk/pull/4070 From iklam at openjdk.java.net Tue May 18 18:56:46 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 18 May 2021 18:56:46 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls [v2] In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4070/files - new: https://git.openjdk.java.net/jdk/pull/4070/files/f1e1e276..b31408a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4070&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4070&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4070/head:pull/4070 PR: https://git.openjdk.java.net/jdk/pull/4070 From gziemski at openjdk.java.net Tue May 18 19:29:03 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 18 May 2021 19:29:03 GMT Subject: RFR: 8267339: macos attempt_reserve_memory_at(arg1, arg2, true) failure Message-ID: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> After adding the fix for https://bugs.openjdk.java.net/browse/JDK-8262952 #3865 on macOS aarch64, things broke on macOS x64. For my initial analysis please see https://bugs.openjdk.java.net/browse/JDK-8267339 The real fix for this issue is tracked by JDK-8267339, however, here we need a quick workaround to get the build fixed, so this is a temporary workaround where we disable the test in question until we have the real fix. ------------- Commit messages: - temporarily disable release_multi_mappings test on macOS x64 Changes: https://git.openjdk.java.net/jdk/pull/4100/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267339 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4100.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4100/head:pull/4100 PR: https://git.openjdk.java.net/jdk/pull/4100 From hseigel at openjdk.java.net Tue May 18 20:54:38 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 18 May 2021 20:54:38 GMT Subject: RFR: 8267339: macos attempt_reserve_memory_at(arg1, arg2, true) failure In-Reply-To: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> References: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> Message-ID: On Tue, 18 May 2021 19:13:25 GMT, Gerard Ziemski wrote: > After adding the fix for https://bugs.openjdk.java.net/browse/JDK-8262952 #3865 on macOS aarch64, things broke on macOS x64. For my initial analysis please see https://bugs.openjdk.java.net/browse/JDK-8267339 > > The real fix for this issue is tracked by JDK-8267339, however, here we need a quick workaround to get the build fixed, so this is a temporary workaround where we disable the test in question until we have the real fix. Changes look good and trivial. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4100 From gziemski at openjdk.java.net Tue May 18 21:48:39 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 18 May 2021 21:48:39 GMT Subject: RFR: 8267339: macos attempt_reserve_memory_at(arg1, arg2, true) failure In-Reply-To: References: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> Message-ID: On Tue, 18 May 2021 20:52:14 GMT, Harold Seigel wrote: > Changes look good and trivial. > Harold Thank you Harold for a quick review! The 2 builds after the failures seem to be OK, so I will wait for either @dholmes-ora and/or @dcubed-ojdk to chime in, whether we should push this in or not... If either of them think we need it in, we will be ready. ------------- PR: https://git.openjdk.java.net/jdk/pull/4100 From mr at openjdk.java.net Tue May 18 23:01:05 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 18 May 2021 23:01:05 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Fix up IllegalAccessTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4015/files - new: https://git.openjdk.java.net/jdk/pull/4015/files/1c14998e..cde0adbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4015&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4015.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4015/head:pull/4015 PR: https://git.openjdk.java.net/jdk/pull/4015 From mr at openjdk.java.net Tue May 18 23:01:07 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Tue, 18 May 2021 23:01:07 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 08:54:23 GMT, Alan Bateman wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove now-unnecessary uses and mentions of the --illegal-access option > > test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 26: > >> 24: /** >> 25: * @test >> 26: * @requires vm.compMode != "Xcomp" > > I think `@requires vm.compMode != "Xcomp" was added because the test took too long with -Xcomp. I think it can be dropped now. Dropped. > test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 37: > >> 35: >> 36: /** >> 37: * Basic test of --illegal-access=value to deny or permit access to JDK internals. > > The comment should probably be updated as the test no longer tests denying or permitting access. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From dholmes at openjdk.java.net Tue May 18 23:39:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 23:39:41 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls [v2] In-Reply-To: References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: On Tue, 18 May 2021 18:56:46 GMT, Ioi Lam wrote: >> `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. >> >> The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. >> >> >> Skipping org/eclipse/osgi/util/NLS: Signed JAR >> Skipping org/eclipse/osgi/util/NLS: Signed JAR >> Skipping org/eclipse/osgi/util/NLS: Signed JAR >> >> >> BTW, to make the code a little easier to read, I also changed >> >> >> warn_excluded(k, "Failed verification"); >> return true; >> >> >> to >> >> >> return warn_excluded(k, "Failed verification"); > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments LGTM. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4070 From jiefu at openjdk.java.net Tue May 18 23:48:53 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 23:48:53 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' Message-ID: Hi all, Please review the small fix which fixes the failure on x86_32. Thanks. Best regards, Jie ------------- Commit messages: - 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' Changes: https://git.openjdk.java.net/jdk/pull/4104/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4104&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267351 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4104/head:pull/4104 PR: https://git.openjdk.java.net/jdk/pull/4104 From dholmes at openjdk.java.net Wed May 19 00:16:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 19 May 2021 00:16:38 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:40:54 GMT, Jie Fu wrote: > Hi all, > > Please review the small fix which fixes the failure on x86_32. > > Thanks. > Best regards, > Jie This seems reasonable. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4104 From darcy at openjdk.java.net Wed May 19 00:30:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 May 2021 00:30:10 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v7] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into 8266530 - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Respond to review feedback. - 8266530: HotSpot changes for JEP 306 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/8925f992..2cdbd56b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=05-06 Stats: 12756 lines in 393 files changed: 5932 ins; 4972 del; 1852 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From darcy at openjdk.java.net Wed May 19 00:30:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 19 May 2021 00:30:10 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v6] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 07:35:03 GMT, David Holmes wrote: > > > Hi Joe, > > In classfileparser.cpp should this: > > else if ((flags & JVM_ACC_STATIC) == JVM_ACC_STATIC) { > flags &= JVM_ACC_STATIC | JVM_ACC_STRICT; > > also be conditional on !major_gte_17? > > Thanks, > David Hi David, Pushed one way to implement the conditionality; thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/3891 From jiefu at openjdk.java.net Wed May 19 01:25:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 01:25:40 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 09:43:26 GMT, Aleksey Shipilev wrote: > Seems like GHA is barfing up due to infrastructure issues. Please re-start the jobs, once current run finishes. Hi @shipilev , Some jobs seem to be blocked. But I think the unfinished jobs make no sense since they don't cover the affected changes at all. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From jiefu at openjdk.java.net Wed May 19 01:38:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 01:38:40 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:13:48 GMT, David Holmes wrote: > This seems reasonable. > > Thanks, > David Thanks @dholmes-ora . ------------- PR: https://git.openjdk.java.net/jdk/pull/4104 From ccheung at openjdk.java.net Wed May 19 01:55:47 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 19 May 2021 01:55:47 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:40:54 GMT, Jie Fu wrote: > Hi all, > > Please review the small fix which fixes the failure on x86_32. > > Thanks. > Best regards, > Jie Looks good. Can you add the current bug id to the `@bug` line? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4104 From jiefu at openjdk.java.net Wed May 19 02:07:56 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 02:07:56 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the small fix which fixes the failure on x86_32. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add bug ID ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4104/files - new: https://git.openjdk.java.net/jdk/pull/4104/files/4cce86be..c944d516 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4104&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4104&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4104.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4104/head:pull/4104 PR: https://git.openjdk.java.net/jdk/pull/4104 From jiefu at openjdk.java.net Wed May 19 02:07:56 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 02:07:56 GMT Subject: RFR: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 01:52:54 GMT, Calvin Cheung wrote: > Looks good. Can you add the current bug id to the `@bug` line? Bug id has been added. Thanks @calvinccheung . ------------- PR: https://git.openjdk.java.net/jdk/pull/4104 From dholmes at openjdk.java.net Wed May 19 02:45:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 19 May 2021 02:45:48 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v7] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:30:10 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into 8266530 > - Restore previous is_strict cdoe in method.hpp. > - Merge branch 'master' into 8266530 > - Make methods strict on IA32. > - Merge branch 'master' into 8266530 > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Latest update seems fine. Approving under the assumption these changes reflect the final spec. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3891 From stuefe at openjdk.java.net Wed May 19 04:10:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 19 May 2021 04:10:40 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 06:50:12 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. >> >> We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 >> [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > -XX:MaxMetaspaceSize=8m LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4076 From iklam at openjdk.java.net Wed May 19 05:20:00 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 May 2021 05:20:00 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls [v3] In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8267191-avoid-repeated-should_be_excluded - @dholmes-ora comments - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into 8267191-avoid-repeated-should_be_excluded - 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls ------------- Changes: https://git.openjdk.java.net/jdk/pull/4070/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4070&range=02 Stats: 77 lines in 2 files changed: 28 ins; 22 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4070.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4070/head:pull/4070 PR: https://git.openjdk.java.net/jdk/pull/4070 From david.holmes at oracle.com Wed May 19 05:53:01 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 May 2021 15:53:01 +1000 Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On 18/05/2021 6:25 pm, Robbin Ehn wrote: > On Tue, 11 May 2021 11:59:23 GMT, Robbin Ehn wrote: >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ >> >> Hi Robbin, >> >> On 17/05/2021 11:02 pm, Robbin Ehn wrote: >> >>> Please consider this change-set which address the issue on hand. >>> I identified two problems: >>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >>> Fixed by leaving the handshakee being processed in queue until completed. >> >> Sorry but I'm not seeing how leaving or removing the op from the queue >> impacts things here. Which thread is reading the queue and seeing a >> wrong value? > > When poll is armed the handshakee must go to slow path and lock the HandshakeState lock if: > - 1: There is handshake operation to be processed > - 2: Some-else is in the middle of processing a handshake operation for this handshakee > > By having having a non-empty queue if 1 or 2 is true, the handshakee can just ask if there is a non-empty queue. > If so go to slow path and grab the HandshakeState lock. > > Now 1 is checked with queue head and 2 is checked with is_locked(). > > But since the thread locking, storing _owner, can do this unordered, it may store the owner field after it have read our thread state, e.g. blocked. Okay ... I'm trying to decide if we have a bug in our Mutex implementation, or whether the use of is_locked() is incorrect. The problem is that checking _owner is not sufficient to know if a Mutex is locked because that is a stand-alone action that happens after the actual locking takes place. Even if we fixed the ordering issue by performing a fence() after storing _owner, that would not fix the basic problem. So any use of Mutex::is_locked() has to be treated with suspicion as it can return false when the Mutex actually is locked. So setting that aside I'm happy to see should_process() and the use of is_locked() disappear, and I will re-examine the PR with a fresh perspective. :) Thanks, David ----- > What we do in three different scenarios are: > Handshaker adds an operation: > store queue > store poll > > Handshaker processing do: > store _owner (lock) > load queue > load poll > load thread state > > Handshakee polling path do: > store state > load poll > load owner > load queue > > ############################################ > With the un-ordered characteristics of _owner field, it looks like it could play out like this: > > Handshakee: state blocked > Handshaker A processor: add: store queue OP Z > Handshaker B processor: processes OP Z and store queue => NULL > Handshaker A processor: add: store poll > Handshaker A processor: LOCK HandshakeState lock (_owner is still NULL) > Handshaker C processor: add: store queue OP X > Handshaker A processor: load queue (sees X) > Handshaker A processor: load poll (armed) > Handshaker A processor: load thread state // OK blocked > Handshakee T target : store state // unsafe > Handshakee T target : load poll // armed > Handshakee T target : load owner // NULL > Handshaker A processor: store _owner (non-NULL) // re-ordered here !! > Handshaker A processor: store queue (NULL) > Handshakee T target : load queue // NULL > Handshakee T target : disarm // ERROR !!!! > >> >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3973 > From alanb at openjdk.java.net Wed May 19 06:24:44 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 May 2021 06:24:44 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From jiefu at openjdk.java.net Wed May 19 07:20:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 07:20:47 GMT Subject: Integrated: 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' In-Reply-To: References: Message-ID: <3eAss36GBFiC2CnPZyr0FKiqYzo3ma3FTd8bFh1P1BA=.a0f2f7d1-4074-41fc-8f96-c532097a8e2b@github.com> On Tue, 18 May 2021 23:40:54 GMT, Jie Fu wrote: > Hi all, > > Please review the small fix which fixes the failure on x86_32. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 3f883e8f Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/3f883e8f0d8811e47999d7fbe3d9784f59d0ac09 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8267351: runtime/cds/SharedBaseAddress.java fails on x86_32 due to Unrecognized VM option 'UseCompressedOops' Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/4104 From rehn at openjdk.java.net Wed May 19 07:26:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:14 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: Message-ID: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn 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: - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/1c6448e3..a8b8469c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=02-03 Stats: 23290 lines in 735 files changed: 8980 ins; 9379 del; 4931 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:17 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:17 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Updated, passed t1-t7 och local stress-testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:19 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 06:04:19 GMT, David Holmes wrote: > Hi Robbin, > > Sorry for the delay in getting through this. > > Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. > > Thanks, > David Thanks for looking at, update after comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:20 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:02:12 GMT, Richard Reingruber wrote: > Hi Robbin, > > there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good. > > Cheers, Richard. Thanks and thanks for finding the two issues, updated! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From shade at openjdk.java.net Wed May 19 09:06:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 May 2021 09:06:46 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 06:50:12 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. >> >> We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 >> [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > -XX:MaxMetaspaceSize=8m Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From jiefu at openjdk.java.net Wed May 19 09:06:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 09:06:47 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Wed, 19 May 2021 04:07:39 GMT, Thomas Stuefe wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> -XX:MaxMetaspaceSize=8m > > LGTM Thanks @tstuefe and @shipilev . ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From jiefu at openjdk.java.net Wed May 19 09:06:47 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 09:06:47 GMT Subject: Integrated: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 In-Reply-To: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: <2e2kMdCVSG-13HsAwBbxcSVOsJFduO0RfpVOxGqa-0I=.02e778d1-f332-4de5-9984-70dbc0f03791@github.com> On Mon, 17 May 2021 23:28:43 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. > > We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 This pull request has now been integrated. Changeset: 2d407e12 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/2d407e12fac1bdf29d339754f234227894416426 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 Reviewed-by: stuefe, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From lzang at openjdk.java.net Wed May 19 11:55:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 19 May 2021 11:55:12 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - fix build issue after rebase and fix one issue - Merge branch 'master' - Merge branch 'master' into pd - update copyright info - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=24 Stats: 835 lines in 5 files changed: 648 ins; 57 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From ddong at openjdk.java.net Wed May 19 12:01:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 19 May 2021 12:01:42 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v8] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 08:37:11 GMT, Stefan Karlsson wrote: >> Hi, >> I think it makes sense. >> How about filing a new JBS issue to fix the problem you mentioned or you think we should fix it in this patch? > > I created a CR for this: > https://bugs.openjdk.java.net/browse/JDK-8267303 > > but I still think that this usage should not be introduced in this patch. @stefank Could you review it again? Thanks, Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From lzang at openjdk.java.net Wed May 19 12:02:00 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 19 May 2021 12:02:00 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: <9yxlJK34rPBqiP47CNcvVmr_zdd3wMNUZblx2EQWVA4=.437cb8bf-7dd8-47e0-9351-51478fd8c0bd@github.com> On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> code refine and typo fix > > I think you still need to undo the JMap.java changes since they are now being handled by #3598 Hi Chris (@plummercj), May I ask your help to remove the `csr` label? As we discussed before, there is no need for this PR to have CSR. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From hseigel at openjdk.java.net Wed May 19 12:45:41 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 19 May 2021 12:45:41 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Hotspot changes look good. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4015 From rrich at openjdk.java.net Wed May 19 14:28:48 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 19 May 2021 14:28:48 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Just one more, rather unimportant comment... Either way: LGTM! Thanks, Richard. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > 380: > 381: _recursions = 0; > 382: ret = simple_wait(self, millis); IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. _recursions = 0; ret = simple_wait(self, millis); _recursions = save; ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From stefank at openjdk.java.net Wed May 19 14:48:44 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 19 May 2021 14:48:44 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:39:04 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > remote LogMinObjAlignmentInBytes The identity_hash() changes look good. FWIW, some allocators return 16 byte aligned memory chunks, so shifting by 3 might leave a non-set LSB. Maybe when fixing JDK-8267303, we should also consider if the shift should be 3 or 4. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Wed May 19 15:14:43 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 19 May 2021 15:14:43 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:45:34 GMT, Stefan Karlsson wrote: > The identity_hash() changes look good. > > FWIW, some allocators return 16 byte aligned memory chunks, so shifting by 3 might leave a non-set LSB. Maybe when fixing JDK-8267303, we should also consider if the shift should be 3 or 4. Thank you! @iwanowww please help sponsor it if there is no other problem, thanks in advance : ) ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From jiefu at openjdk.java.net Wed May 19 15:17:38 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 15:17:38 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: On Tue, 18 May 2021 05:12:33 GMT, Thomas Stuefe wrote: > Hi Jie, > > You can safely get by with less. A very safe bet for all platforms would be: > > * 256m heap > * 8m MaxMetaspaceSize > > The latter could be probably reduced more (the smaller metaspace, the faster the test comes to conclusion), down to 6m or 4m. On my machine 4m works for both 64 and 32bit. But 8m is probably safe on all platforms. > > Cheers, Thomas Maybe -Xmx256m is not enough. OOME on aarch64: https://bugs.openjdk.java.net/browse/JDK-8267404 Will do more investigation tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From stuefe at openjdk.java.net Wed May 19 15:28:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 19 May 2021 15:28:16 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: - fixes - made kernel 3.8 mandatory - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out - wip ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4064/files - new: https://git.openjdk.java.net/jdk/pull/4064/files/d5785cbf..0e2a9e31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=03-04 Stats: 59 lines in 1 file changed: 42 ins; 7 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Wed May 19 15:32:48 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 19 May 2021 15:32:48 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v4] In-Reply-To: <00rCjLEBHmC64hGpkU7j1TidO61K0eV4AgeliEelBq8=.bbaacabf-555e-4d6e-887c-8c4c51e7b4c1@github.com> References: <00rCjLEBHmC64hGpkU7j1TidO61K0eV4AgeliEelBq8=.bbaacabf-555e-4d6e-887c-8c4c51e7b4c1@github.com> Message-ID: On Tue, 18 May 2021 12:32:23 GMT, Stefan Johansson wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java >> >> Co-authored-by: Aleksey Shipil?v >> - Update test/hotspot/jtreg/runtime/os/TestTracePageSizes.java >> >> oops >> >> Co-authored-by: Aleksey Shipil?v > > Did a quick test now with THP configured to `always` but running with `-XX:-UseLargePages -XX:-UseTransparentHugePages`. It gives me: > > 80000000-ffe00000 rw-p 00000000 00:00 0 > Size: 2095104 kB > KernelPageSize: 4 kB > MMUPageSize: 4 kB > ... > AnonHugePages: 2095104 kB > THPeligible: 1 > VmFlags: rd wr mr mw me ac sd > > So no `hg` flag as expected. Hi @kstefanj , @shipilev , I changed the test so that: - we skip out if kernel < 3.8. This means we can rely on a sane set of tags from the smaps file. - I skipped also for ppc because I found that the semantics of some tags in smaps differ and I honestly never used hugetlbfs on ppc; if it becomes an issue, we can spend more time on this. - I reverted some of my earlier changes; now we again require all information to be there (so no null handling for missing smaps information in `RangeWithPageSize`. - added some comments Note that even though we skip out of the test we still at least start the VMs and go through VM initialization. That is totally fine by me since this is a good test that the VM survives these variations of large page flags (eg we found unrelated crashes on ppc with https://github.com/openjdk/jdk/pull/1153 that way). Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Wed May 19 15:39:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 19 May 2021 15:39:03 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> Message-ID: <_xJw2gUqwYRLLs15kXRYcd7jk68mV32fbHfsKRJnWm0=.fbb90190-9f63-41d4-a676-168594bf6622@github.com> On Tue, 18 May 2021 06:50:12 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `-XX:MaxRAMPercentage=0` will be 0 if JTREG_JOBS > 25 [1]. >> >> We can also reproduce the bug by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> This fix will make it to be more robust, which is suggested by @shipilev [2] and many thanks to him. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 >> [2] https://github.com/openjdk/jdk/pull/4062#pullrequestreview-661198240 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > -XX:MaxMetaspaceSize=8m Hmm... sorry for that. Weird though since I would not have expected a lot of platform dependency here (apart from 32 vs 64bit). Ideally this test should be rewritten to load large classes, not these tiny ones, to get a better ratio between metaspace and heap space. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From dcubed at openjdk.java.net Wed May 19 15:41:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 19 May 2021 15:41:57 GMT Subject: RFR: 8267407 ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 Message-ID: A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64. ------------- Commit messages: - 8267407 ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/4117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267407 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4117/head:pull/4117 PR: https://git.openjdk.java.net/jdk/pull/4117 From dcubed at openjdk.java.net Wed May 19 15:48:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 19 May 2021 15:48:43 GMT Subject: RFR: 8267339: Temporarily disable os.release_multi_mappings_vm on macOS x64 In-Reply-To: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> References: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> Message-ID: On Tue, 18 May 2021 19:13:25 GMT, Gerard Ziemski wrote: > After adding the fix for https://bugs.openjdk.java.net/browse/JDK-8262952 #3865 on macOS aarch64, things broke on macOS x64. For my initial analysis please see https://bugs.openjdk.java.net/browse/JDK-8267339 > > The real fix for this issue is tracked by JDK-8267339, however, here we need a quick workaround to get the build fixed, so this is a temporary workaround where we disable the test in question until we have the real fix. Thumbs up. Please integrate this "ProblemListing". Thanks. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4100 From shade at openjdk.java.net Wed May 19 16:04:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 May 2021 16:04:45 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:28:16 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: > > - fixes > - made kernel 3.8 mandatory > - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out > - wip This looks fine to me, modulo a few nits. test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 121: > 119: debug("kernelVersion " + Long.toHexString(kernelVersion)); > 120: return kernelVersion; > 121: } Let's not do any bit magic? Just inline this to the only use and do the proper branchy "if"? test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 243: > 241: this.end = Long.parseUnsignedLong(end, 16); > 242: this.pageSize = Long.parseLong(pageSize); > 243: Restore this newline? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4064 From dcubed at openjdk.java.net Wed May 19 16:12:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 19 May 2021 16:12:06 GMT Subject: RFR: 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 [v2] In-Reply-To: References: Message-ID: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> > A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8267409 ProblemList gc/epsilon/TestClasses.java on linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4117/files - new: https://git.openjdk.java.net/jdk/pull/4117/files/9be5adc7..fd335cfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4117&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4117&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4117.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4117/head:pull/4117 PR: https://git.openjdk.java.net/jdk/pull/4117 From tschatzl at openjdk.java.net Wed May 19 16:12:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 19 May 2021 16:12:07 GMT Subject: RFR: 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 [v2] In-Reply-To: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> References: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> Message-ID: On Wed, 19 May 2021 16:09:07 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8267409 ProblemList gc/epsilon/TestClasses.java on linux-x64 Lgtm and trivial. Still good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4117 From dcubed at openjdk.java.net Wed May 19 16:12:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 19 May 2021 16:12:07 GMT Subject: RFR: 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 [v2] In-Reply-To: References: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> Message-ID: On Wed, 19 May 2021 15:55:56 GMT, Thomas Schatzl wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267409 ProblemList gc/epsilon/TestClasses.java on linux-x64 > > Lgtm and trivial. @tschatzl - I added a second ProblemListing in the same file. Would you be so kind as to re-review? Thanks! > Still good. @tschatzl - Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4117 From dcubed at openjdk.java.net Wed May 19 16:12:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 19 May 2021 16:12:08 GMT Subject: Integrated: 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:35:14 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64. This pull request has now been integrated. Changeset: 64e2479b Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/64e2479bf6e0ceccda16c076758e23e85310d524 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 8267409: ProblemList gc/epsilon/TestClasses.java on linux-x64 Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/4117 From mchung at openjdk.java.net Wed May 19 16:37:41 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 19 May 2021 16:37:41 GMT Subject: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix up IllegalAccessTest Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From gziemski at openjdk.java.net Wed May 19 16:45:45 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 19 May 2021 16:45:45 GMT Subject: Integrated: 8267339: Temporarily disable os.release_multi_mappings_vm on macOS x64 In-Reply-To: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> References: <4WcJcXADoSSjjo3x2_x7cN4ChKBMFoc5f8rBNMoMLHY=.7071b784-8054-4eeb-8647-818c931ffa25@github.com> Message-ID: On Tue, 18 May 2021 19:13:25 GMT, Gerard Ziemski wrote: > After adding the fix for https://bugs.openjdk.java.net/browse/JDK-8262952 #3865 on macOS aarch64, things broke on macOS x64. For my initial analysis please see https://bugs.openjdk.java.net/browse/JDK-8267339 > > The real fix for this issue is tracked by JDK-8267339, however, here we need a quick workaround to get the build fixed, so this is a temporary workaround where we disable the test in question until we have the real fix. This pull request has now been integrated. Changeset: 237fee8b Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/237fee8bbdc7f239aa18b7780392ff3222589914 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8267339: Temporarily disable os.release_multi_mappings_vm on macOS x64 Reviewed-by: hseigel, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4100 From gziemski at openjdk.java.net Wed May 19 16:48:44 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 19 May 2021 16:48:44 GMT Subject: RFR: 8267407: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64 [v2] In-Reply-To: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> References: <2XFxpVjvAdas96p1poixWrXiGn_ZTF9D6Zq7Yl_Ut8k=.6a604b15-db14-4a89-ae02-3fe139b93593@github.com> Message-ID: On Wed, 19 May 2021 16:12:06 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java on linux-aarch64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8267409 ProblemList gc/epsilon/TestClasses.java on linux-x64 Looks good, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4117 From sjohanss at openjdk.java.net Wed May 19 18:45:49 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 19 May 2021 18:45:49 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:28:16 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: > > - fixes > - made kernel 3.8 mandatory > - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out > - wip Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Wed May 19 18:45:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 19 May 2021 18:45:51 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:00:45 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: >> >> - fixes >> - made kernel 3.8 mandatory >> - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out >> - wip > > test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 121: > >> 119: debug("kernelVersion " + Long.toHexString(kernelVersion)); >> 120: return kernelVersion; >> 121: } > > Let's not do any bit magic? Just inline this to the only use and do the proper branchy "if"? +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From sjohanss at openjdk.java.net Wed May 19 19:15:49 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 19 May 2021 19:15:49 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:28:16 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: > > - fixes > - made kernel 3.8 mandatory > - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out > - wip Changes requested by sjohanss (Reviewer). test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 44: > 42: * @requires vm.gc != "Z" > 43: * @run main/othervm -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseLargePages -XX:LargePageSizeInBytes=2m TestTracePageSizes > 44: * @run main/othervm -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseLargePages -XX:LargePageSizeInBytes=1g TestTracePageSizes Just realized that this test should probably not set `-Xmx128m` since we try to use 1g pages. What will happen is that the heap will be rounded up to 1G (the alignment logic here is a bit strange) so we will still test it, but it feels a bit backwards. Maybe set the heap to 1g in this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From iklam at openjdk.java.net Wed May 19 19:34:47 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 May 2021 19:34:47 GMT Subject: RFR: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls [v3] In-Reply-To: References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: On Tue, 18 May 2021 11:34:35 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8267191-avoid-repeated-should_be_excluded >> - @dholmes-ora comments >> - fixed merge >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8267191-avoid-repeated-should_be_excluded >> - 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls > > Looks good! Thanks @coleenp and @dholmes-ora for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4070 From iklam at openjdk.java.net Wed May 19 19:34:48 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 19 May 2021 19:34:48 GMT Subject: Integrated: 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls In-Reply-To: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> References: <87g-2BPdFYJJtaNjsm8sl55WynvQFc6pMsFyj5BQ6dY=.c1841b4c-90db-4074-9fb5-952dd5c0ff50@github.com> Message-ID: On Mon, 17 May 2021 17:39:32 GMT, Ioi Lam wrote: > `SystemDictionaryShared::should_be_excluded` is called during CDS dump time to see if a class should be excluded from the archive. This function calls itself to check super types. As a result, some classes many be checked more than once. > > The repeated calls slows down dumping. Also, If a class is excluded, we will see multiple warning messages like this, which is too verbose and confusing. > > > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > Skipping org/eclipse/osgi/util/NLS: Signed JAR > > > BTW, to make the code a little easier to read, I also changed > > > warn_excluded(k, "Failed verification"); > return true; > > > to > > > return warn_excluded(k, "Failed verification"); This pull request has now been integrated. Changeset: b961f253 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/b961f2535c9508d6f8e580b8bf53538d6f72b27c Stats: 77 lines in 2 files changed: 28 ins; 22 del; 27 mod 8267191: Avoid repeated SystemDictionaryShared::should_be_excluded calls Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/4070 From vromero at openjdk.java.net Wed May 19 20:46:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 20:46:23 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v8] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06-07 Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From jiefu at openjdk.java.net Thu May 20 04:26:34 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 20 May 2021 04:26:34 GMT Subject: RFR: 8267293: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails when JTREG_JOBS > 25 [v2] In-Reply-To: <_xJw2gUqwYRLLs15kXRYcd7jk68mV32fbHfsKRJnWm0=.fbb90190-9f63-41d4-a676-168594bf6622@github.com> References: <-1hTcSUlr983ZQ2gUdg30cMNrHb31P32BWHzvR12YRg=.45f04528-1313-481d-99fa-f72ceb5ca236@github.com> <_xJw2gUqwYRLLs15kXRYcd7jk68mV32fbHfsKRJnWm0=.fbb90190-9f63-41d4-a676-168594bf6622@github.com> Message-ID: On Wed, 19 May 2021 15:34:45 GMT, Thomas Stuefe wrote: > Hmm... sorry for that. Weird though since I would not have expected a lot of platform dependency here (apart from 32 vs 64bit). > > Ideally this test should be rewritten to load large classes, not these tiny ones, to get a better ratio between metaspace and heap space. Maybe, there is something special on Oracle's aarch64 platforms. All our aarch64 machines fail to reproduce the OOME. I've asked the help of @dcubed-ojdk to test with `-Xmx1g` and `-Xmx2g`. If it still fails, I'd like to revert the change. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4076 From dholmes at openjdk.java.net Thu May 20 04:43:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 04:43:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Updates seem fine. Lucky _waiters was unused :) Will take another full pass over the changes. Thanks, David src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _exited; For consistency with raw monitor code this would _om_exited ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From lzang at openjdk.java.net Thu May 20 05:10:46 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 20 May 2021 05:10:46 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 11:55:12 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - fix build issue after rebase and fix one issue > - Merge branch 'master' > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b Dear All, May I get more review about the PR? Thanks! BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From stuefe at openjdk.java.net Thu May 20 05:18:32 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 20 May 2021 05:18:32 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 19:12:27 GMT, Stefan Johansson wrote: >> Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: >> >> - fixes >> - made kernel 3.8 mandatory >> - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out >> - wip > > test/hotspot/jtreg/runtime/os/TestTracePageSizes.java line 44: > >> 42: * @requires vm.gc != "Z" >> 43: * @run main/othervm -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseLargePages -XX:LargePageSizeInBytes=2m TestTracePageSizes >> 44: * @run main/othervm -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseLargePages -XX:LargePageSizeInBytes=1g TestTracePageSizes > > Just realized that this test should probably not set `-Xmx128m` since we try to use 1g pages. What will happen is that the heap will be rounded up to 1G (the alignment logic here is a bit strange) so we will still test it, but it feels a bit backwards. Maybe set the heap to 1g in this case? Good point. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From thomas.stuefe at gmail.com Thu May 20 05:21:24 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 20 May 2021 07:21:24 +0200 Subject: [11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads In-Reply-To: <53640CDE-B41D-4E3E-8861-96C8A54E9C32@azul.com> References: <53640CDE-B41D-4E3E-8861-96C8A54E9C32@azul.com> Message-ID: Thanks, Sergey! ..Thomas On Wed, May 19, 2021 at 8:41 PM Sergey Nazarkin wrote: > Checked on arm32: new test fails without patch and passes with the patch > > > > > > > On May 11, 2021, at 09:07, Thomas St?fe wrote: > > > > Hi, > > > > I'd like reviews for this downport, please. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8257828 > > Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb > > Original Review: https://git.openjdk.java.net/jdk/pull/1695 > > > > This patch does two things: > > > > 1) On Posix platforms it fixes SafeFetch to work in all threads, not only > > in JavaThreads. In non-JavaThreads before this patch it would crash. > > > > The patch is totally trivial. In the signal handler, when handling > > SafeFetch, there was a condition that Thread != NULL and be a JavaThread. > > This condition was unnecessary. All SafeFetch handling needs is a valid > > context. The Patch moves SafeFetch handling out of the is-JavaThread > > condition. > > > > 2) On Windows we did not have the problem; however there is the > > `Handle_Exception` function handling SafeFetch among other things, which > > may be called with a non-java thread, but then forcibly casts the Thread* > > to JavaThread. > > > > 11u patch: > > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads > > > > The original patch does not apply, at all. The reason for this is that we > > consolidated common functionality of the many cpu+arch signal handlers to > > one function, in os_posix.cpp. This happened in JDK16 and I do not want > to > > backport this cleanup change to 11. For this patch, it means that the > > posix-related fixes practically had to be rewritten for each and every > > signal handler. Each fix is primitive however, since it just moves > > SafeFetch handling around, but every signal handler is a tiny bit > different. > > > > I tested this patch for several weeks in our systems on Linux > > ppc/ppcle/x64/s390/aarch64, AIX, Solaris and Mac, no problems surfaced. > > > > I did not test on 32bit arm. > > > > Thanks, Thomas > > From stuefe at openjdk.java.net Thu May 20 05:29:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 20 May 2021 05:29:57 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: References: Message-ID: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: final review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4064/files - new: https://git.openjdk.java.net/jdk/pull/4064/files/0e2a9e31..09319ae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4064&range=04-05 Stats: 10 lines in 1 file changed: 2 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4064.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4064/head:pull/4064 PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Thu May 20 05:29:58 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 20 May 2021 05:29:58 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v5] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:28:16 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision: > > - fixes > - made kernel 3.8 mandatory > - Merge branch 'JDK-8267155-runtime-os-TestTracePageSize-times-out' of github.com:tstuefe/jdk into JDK-8267155-runtime-os-TestTracePageSize-times-out > - wip Final changes. Nobody liked my bit shifting, so removed. I upped the heap size to 2g for the largepagesizeinbytes=1g page test. One nice thing about the new parser is that with debug=true we now can observe the parsing, including the content of the parsed smaps file in the jtr output. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From shade at openjdk.java.net Thu May 20 05:36:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 20 May 2021 05:36:31 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> References: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> Message-ID: <1ymNWfQos40_qhEK8G6paCyRlGM5doyCh7ASprUBKQY=.354c3a17-e064-4fe1-8f55-10f702599087@github.com> On Thu, 20 May 2021 05:29:57 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > final review feedback Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4064 From dholmes at openjdk.java.net Thu May 20 07:03:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 07:03:43 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> References: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> Message-ID: On Mon, 17 May 2021 07:02:30 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: >> >>> 46: // The rules are: >>> 47: // - We must never safepoint poll if raw monitor is owned. >>> 48: // - We may safepoint poll before it is owned and after it has been released. >> >> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. > > This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: > JavaThread: > -lock RM > LOOP { > -wait RM > -do stufff with data from VM thread > } > -unlock RM > > The user do not call into the VM/Java. > > VM Thread: > -safepoint > -lock RM > -notify RM > -unlock RM > > If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. > > If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. > But he would also deadlock if he used a pthread mutex because that code would be buggy. Okay I understand what you are referring to now - thanks. It is a bit concerning that Raw Monitor wait is specified to be callback safe as that means we can legitimately block the VMThread indefinitely! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Thu May 20 07:03:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 07:03:42 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Hi Robbin, Overall this looks good to me, but there is one issue that needs fixing (partially pre-existing but now also affecting ObjectMonitor::enter). Other minor comments below. Thanks, David src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236: > 234: > 235: template > 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition { Can we add a comment before this template definition please: // Perform a transition to _thread_blocked and take a call-back to be executed before // SafepointMechanism::process_if_requested when returning to the VM. This allows us // to perform an "undo" action if we might block processing a safepoint/handshake operation // (such as thread suspension). src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245: > 243: // Once we are blocked vm expects stack to be walkable > 244: thread->frame_anchor()->make_walkable(thread); > 245: thread->set_thread_state(_thread_blocked); This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this: `current->frame_anchor()->make_walkable(current);` `// Thread must be walkable before it is blocked.` `// Read in reverse order.` `OrderAccess::storestore();` `for (;;) {` ` current->set_thread_state(_thread_blocked);` src/hotspot/share/runtime/objectMonitor.cpp line 448: > 446: // Completed the tranisition. > 447: SafepointMechanism::process_if_requested(current); > 448: current->set_thread_state(_thread_in_vm); The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 07:10:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:10:34 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > Just one more, rather unimportant comment... > > Either way: LGTM! > > Thanks, Richard. Thanks! > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > >> 380: >> 381: _recursions = 0; >> 382: ret = simple_wait(self, millis); > > IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. > > In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. > > _recursions = 0; > ret = simple_wait(self, millis); > _recursions = save; Yes, it can be re-written as something below, but is this more readable? _recursions = 0; ret = simple_wait(self, millis); if (self->is_Java_thread()) { // JavaThread re-enter JavaThread* jt = self->as_Java_thread(); { ThreadInVMfromNative tivmfn(jt); for (;;) { ExitOnSuspend eos(this); { ThreadBlockInVMPreprocess tbivmp(jt, eos); simple_enter(jt); } if (!eos.monitor_exited()) { break; } } if (jt->is_interrupted(true)) { ret = M_INTERRUPTED; } } } else { // Non-JavaThread re-enter assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); simple_enter(self); } _recursions = save; ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Thu May 20 07:19:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 17:19:03 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> Message-ID: <892486cc-4564-81e1-b3d8-2922859c78e8@oracle.com> On 20/05/2021 5:10 pm, Robbin Ehn wrote: > On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > >> Just one more, rather unimportant comment... >> >> Either way: LGTM! >> >> Thanks, Richard. > > Thanks! > >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: >> >>> 380: >>> 381: _recursions = 0; >>> 382: ret = simple_wait(self, millis); >> >> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. >> >> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. >> >> _recursions = 0; >> ret = simple_wait(self, millis); >> _recursions = save; > > Yes, it can be re-written as something below, but is this more readable? I'd say yes with two minor modifications: > > _recursions = 0; > ret = simple_wait(self, millis); + // Now we need to re-enter the monitor. For JavaThread's + // we need to manage suspend requests. > if (self->is_Java_thread()) { // JavaThread re-enter > JavaThread* jt = self->as_Java_thread(); > { I think this extra block scope can also go. Cheers, David ----- > ThreadInVMfromNative tivmfn(jt); > for (;;) { > ExitOnSuspend eos(this); > { > ThreadBlockInVMPreprocess tbivmp(jt, eos); > simple_enter(jt); > } > if (!eos.monitor_exited()) { > break; > } > } > if (jt->is_interrupted(true)) { > ret = M_INTERRUPTED; > } > } > } else { // Non-JavaThread re-enter > assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); > simple_enter(self); > } > _recursions = save; > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From rehn at openjdk.java.net Thu May 20 07:19:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:19:35 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Thu, 20 May 2021 05:14:43 GMT, David Holmes wrote: >> Robbin Ehn 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: >> >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236: > >> 234: >> 235: template >> 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition { > > Can we add a comment before this template definition please: > > // Perform a transition to _thread_blocked and take a call-back to be executed before > // SafepointMechanism::process_if_requested when returning to the VM. This allows us > // to perform an "undo" action if we might block processing a safepoint/handshake operation > // (such as thread suspension). Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245: > >> 243: // Once we are blocked vm expects stack to be walkable >> 244: thread->frame_anchor()->make_walkable(thread); >> 245: thread->set_thread_state(_thread_blocked); > > This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this: > `current->frame_anchor()->make_walkable(current);` > `// Thread must be walkable before it is blocked.` > `// Read in reverse order.` > `OrderAccess::storestore();` > `for (;;) {` > ` current->set_thread_state(_thread_blocked);` Good catch, fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _exited; > > For consistency with raw monitor code this would be _om_exited Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 07:31:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:31:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Thu, 20 May 2021 06:03:28 GMT, David Holmes wrote: >> Robbin Ehn 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: >> >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/runtime/objectMonitor.cpp line 448: > >> 446: // Completed the tranisition. >> 447: SafepointMechanism::process_if_requested(current); >> 448: current->set_thread_state(_thread_in_vm); > > The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code. I moved comment and current->set_current_pending_monitor(NULL); into loop. And I set current->set_current_pending_monitor(om); to OM again in ExitOnSuspend if we exit the OM. The thread dump is then identical to what we have today if ~ThreadBlockInVMPreprocess safepoints. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 07:31:38 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:31:38 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 07:22:06 GMT, Robbin Ehn wrote: > Hi Robbin, > > Sorry for the delay in getting through this. > > Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. > > Thanks, > David Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From sjohanss at openjdk.java.net Thu May 20 07:57:35 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 20 May 2021 07:57:35 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> References: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> Message-ID: On Thu, 20 May 2021 05:29:57 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > final review feedback Looks good! ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Thu May 20 08:21:37 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 20 May 2021 08:21:37 GMT Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> References: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> Message-ID: On Thu, 20 May 2021 05:29:57 GMT, Thomas Stuefe wrote: >> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >> >> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >> >> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >> >> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >> >> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >> >> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > final review feedback Thanks Alexey and Stefan. ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From stuefe at openjdk.java.net Thu May 20 08:21:38 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 20 May 2021 08:21:38 GMT Subject: Integrated: 8267155: runtime/os/TestTracePageSizes times out In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:09:32 GMT, Thomas Stuefe wrote: > This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. > > In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. > > I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. > > In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. > > I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. > > Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. > > Thanks, Thomas This pull request has now been integrated. Changeset: 726785b8 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/726785b8d7c18569bddae6a08fa7f61d8d7bd2c4 Stats: 133 lines in 1 file changed: 95 ins; 0 del; 38 mod 8267155: runtime/os/TestTracePageSizes times out Reviewed-by: shade, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/4064 From vromero at openjdk.java.net Thu May 20 09:14:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 May 2021 09:14:33 GMT Subject: Integrated: 8260517: implement Sealed Classes as a standard feature in Java In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. This pull request has now been integrated. Changeset: 0fa9223f Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b Stats: 444 lines in 54 files changed: 51 ins; 275 del; 118 mod 8260517: implement Sealed Classes as a standard feature in Java Co-authored-by: Harold Seigel Co-authored-by: Vicente Romero Reviewed-by: dholmes, mcimadamore, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From david.holmes at oracle.com Thu May 20 10:47:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 20:47:34 +1000 Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: References: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> Message-ID: <07b39037-0800-ae37-b02d-6350b4980e06@oracle.com> Hi Thomas, This test is now failing in our tier 1 testing for linux-aarch64: runtime/os/TestTracePageSizes.java#with-Serial ----------messages:(4/366)---------- command: main -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes reason: User specified action: run main/othervm -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes Mode: othervm [/othervm specified] elapsed time (seconds): 1.182 ----------configuration:(0/0)---------- ----------System.out:(0/0)---------- ----------System.err:(13/846)---------- java.lang.AssertionError: Page sizes mismatch: 64 != 524288 at TestTracePageSizes.main(TestTracePageSizes.java:294) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) I will file a bug and assign to you. If it can't be fixed promptly we will need to backout the change. Thanks, David ----- On 20/05/2021 6:21 pm, Thomas Stuefe wrote: > On Thu, 20 May 2021 05:29:57 GMT, Thomas Stuefe wrote: > >>> This Linux-specific test parses `/proc/self/smaps` using a dotall regular expression. If part of the expression don't match it explodes in complexity, leading to timeouts. >>> >>> In our case, `VmFlags` tag was missing from smaps, which was introduced with kernel 3.8. I am actually not able to determine how slow they were; on one machine they ran for two hours before getting killed. >>> >>> I tried to fiddle with the regular expression and gave up, instead opting to rewrite the parser to get a simple one-pass scan. This is way faster than before - on our old-kernel machines the tests complete in 2 minutes. On new kernels the test is a bit faster too. >>> >>> In addition to rewriting the parser, I added code which copies the smaps file into the test directory before parsing it. I do this to minimize problems should the underlying proc fs content change while parsing, and to have a way to retain the parsed smaps files. >>> >>> I also added a way to feed an external smaps file into the test. Of course the test would fail, but it was a way to test the parser. >>> >>> Unfortunately, this does not make the test succeed. The timeouts are gone, but we have still have no way to know if TPHs are enabled or not. That is a separate issue though. >>> >>> Thanks, Thomas >> >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> final review feedback > > Thanks Alexey and Stefan. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4064 > From david.holmes at oracle.com Thu May 20 11:07:25 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 21:07:25 +1000 Subject: RFR: 8267155: runtime/os/TestTracePageSizes times out [v6] In-Reply-To: <07b39037-0800-ae37-b02d-6350b4980e06@oracle.com> References: <3wmrwR6oz1kuXGAcve1K1GlcxrneUaeuSROvZcsazw8=.19384dff-f0cc-418f-9e49-b593f553f45e@github.com> <07b39037-0800-ae37-b02d-6350b4980e06@oracle.com> Message-ID: <3c0ef7c1-a115-4694-8d0b-38f16be1c46b@oracle.com> Hi Thomas, The test is being problem-listed so a fix is less urgent and backout avoided. Cheers, David On 20/05/2021 8:47 pm, David Holmes wrote: > Hi Thomas, > > This test is now failing in our tier 1 testing for linux-aarch64: > > runtime/os/TestTracePageSizes.java#with-Serial > > > ----------messages:(4/366)---------- > command: main -XX:+AlwaysPreTouch -Xmx128m -Xlog:pagesize:ps-%p.log > -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes > reason: User specified action: run main/othervm -XX:+AlwaysPreTouch > -Xmx128m -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC > -XX:+UseTransparentHugePages TestTracePageSizes > Mode: othervm [/othervm specified] > elapsed time (seconds): 1.182 > ----------configuration:(0/0)---------- > ----------System.out:(0/0)---------- > ----------System.err:(13/846)---------- > java.lang.AssertionError: Page sizes mismatch: 64 != 524288 > ????at TestTracePageSizes.main(TestTracePageSizes.java:294) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > > ????at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > ????at java.base/java.lang.reflect.Method.invoke(Method.java:568) > ????at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > ????at java.base/java.lang.Thread.run(Thread.java:831) > > > I will file a bug and assign to you. If it can't be fixed promptly we > will need to backout the change. > > Thanks, > David > ----- > > On 20/05/2021 6:21 pm, Thomas Stuefe wrote: >> On Thu, 20 May 2021 05:29:57 GMT, Thomas Stuefe >> wrote: >> >>>> This Linux-specific test parses `/proc/self/smaps` using a dotall >>>> regular expression. If part of the expression don't match it >>>> explodes in complexity, leading to timeouts. >>>> >>>> In our case, `VmFlags` tag was missing from smaps, which was >>>> introduced with kernel 3.8. I am actually not able to determine how >>>> slow they were; on one machine they ran for two hours before getting >>>> killed. >>>> >>>> I tried to fiddle with the regular expression and gave up, instead >>>> opting to rewrite the parser to get a simple one-pass scan. This is >>>> way faster than before - on our old-kernel machines the tests >>>> complete in 2 minutes. On new kernels the test is a bit faster too. >>>> >>>> In addition to rewriting the parser, I added code which copies the >>>> smaps file into the test directory before parsing it. I do this to >>>> minimize problems should the underlying proc fs content change while >>>> parsing, and to have a way to retain the parsed smaps files. >>>> >>>> I also added a way to feed an external smaps file into the test. Of >>>> course the test would fail, but it was a way to test the parser. >>>> >>>> Unfortunately, this does not make the test succeed. The timeouts are >>>> gone, but we have still have no way to know if TPHs are enabled or >>>> not. That is a separate issue though. >>>> >>>> Thanks, Thomas >>> >>> Thomas Stuefe has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? final review feedback >> >> Thanks Alexey and Stefan. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4064 >> From rehn at openjdk.java.net Thu May 20 11:37:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:37:35 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> Message-ID: On Thu, 20 May 2021 07:07:20 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: >> >>> 380: >>> 381: _recursions = 0; >>> 382: ret = simple_wait(self, millis); >> >> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. >> >> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. >> >> _recursions = 0; >> ret = simple_wait(self, millis); >> _recursions = save; > > Yes, it can be re-written as something below, but is this more readable? > > > _recursions = 0; > ret = simple_wait(self, millis); > > if (self->is_Java_thread()) { // JavaThread re-enter > JavaThread* jt = self->as_Java_thread(); > { > ThreadInVMfromNative tivmfn(jt); > for (;;) { > ExitOnSuspend eos(this); > { > ThreadBlockInVMPreprocess tbivmp(jt, eos); > simple_enter(jt); > } > if (!eos.monitor_exited()) { > break; > } > } > if (jt->is_interrupted(true)) { > ret = M_INTERRUPTED; > } > } > } else { // Non-JavaThread re-enter > assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); > simple_enter(self); > } > _recursions = save; Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 11:42:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:42:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Review fixes 2 - Merge branch 'master' into 8265753 - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/a8b8469c..6faf1422 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=03-04 Stats: 4768 lines in 204 files changed: 3182 ins; 1013 del; 573 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 11:42:13 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:42:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 20/05/2021 5:10 pm, Robbin Ehn wrote: > > > On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > > > Just one more, rather unimportant comment... > > > Either way: LGTM! > > > Thanks, Richard. > > > > > > Thanks! > > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > > > > 380: > > > > 381: _recursions = 0; > > > > 382: ret = simple_wait(self, millis); > > > > > > > > > IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. > > > In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. > > > ``` > > > _recursions = 0; > > > ret = simple_wait(self, millis); > > > _recursions = save; > > > ``` > > > > > > Yes, it can be re-written as something below, but is this more readable? > > I'd say yes with two minor modifications: > > > _recursions = 0; > > ret = simple_wait(self, millis); > > + // Now we need to re-enter the monitor. For JavaThread's > + // we need to manage suspend requests. > > > if (self->is_Java_thread()) { // JavaThread re-enter > > JavaThread* jt = self->as_Java_thread(); > > { > > I think this extra block scope can also go. > > Cheers, > David > ----- Fixed, thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From akozlov at openjdk.java.net Thu May 20 11:51:32 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 20 May 2021 11:51:32 GMT Subject: RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik wrote: > Please review this patch for call_VM_Base routine. > it's expected there the LR is callee-saved register, but it's not on aarch64. > when InterpreterRuntime::throw_pending_exception is tail-call optimized, > the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR. > It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build. The change looks good to me, but I'm not a formal reviewer. AArch64's StubRoutines::forward_exception_entry below expects LR to point to after the runtime call. Usually LR is preserved by the runtime callee, but this is not required by the ABI [1]. So we need to restore LR after the call. [1] https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d55170c563c3c7940134089176746/aapcs64/aapcs64.rst#general-purpose-registers src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 686: > 684: ldr(lr, Address(rthread, > 685: JavaThread::frame_anchor_offset() > 686: + JavaFrameAnchor::last_Java_pc_offset())); `ldr(lr, Address(rthread, JavaThread::last_Java_pc_offset()))`? Same meaning, but shorter. ------------- Marked as reviewed by akozlov (Committer). PR: https://git.openjdk.java.net/jdk/pull/4115 From aph at openjdk.java.net Thu May 20 13:18:30 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 20 May 2021 13:18:30 GMT Subject: RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik wrote: > Please review this patch for call_VM_Base routine. > it's expected there the LR is callee-saved register, but it's not on aarch64. > when InterpreterRuntime::throw_pending_exception is tail-call optimized, > the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR. > It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 687: > 685: JavaThread::frame_anchor_offset() > 686: + JavaFrameAnchor::last_Java_pc_offset())); > 687: Is this any different from `adr(lr, l)` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4115 From vkempik at openjdk.java.net Thu May 20 15:19:22 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 20 May 2021 15:19:22 GMT Subject: RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash [v2] In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: > Please review this patch for call_VM_Base routine. > it's expected there the LR is callee-saved register, but it's not on aarch64. > when InterpreterRuntime::throw_pending_exception is tail-call optimized, > the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR. > It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build. Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision: Update the fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4115/files - new: https://git.openjdk.java.net/jdk/pull/4115/files/5b7c4cec..edea0a61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4115&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4115&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4115/head:pull/4115 PR: https://git.openjdk.java.net/jdk/pull/4115 From vkempik at openjdk.java.net Thu May 20 15:19:25 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 20 May 2021 15:19:25 GMT Subject: RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash [v2] In-Reply-To: References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: On Thu, 20 May 2021 13:15:35 GMT, Andrew Haley wrote: >> Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the fix > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 687: > >> 685: JavaThread::frame_anchor_offset() >> 686: + JavaFrameAnchor::last_Java_pc_offset())); >> 687: > > Is this any different from `adr(lr, l)` ? this gives exactly same result, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4115 From aph at openjdk.java.net Thu May 20 15:36:37 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 20 May 2021 15:36:37 GMT Subject: RFR: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash [v2] In-Reply-To: References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: On Thu, 20 May 2021 15:19:22 GMT, Vladimir Kempik wrote: >> Please review this patch for call_VM_Base routine. >> it's expected there the LR is callee-saved register, but it's not on aarch64. >> when InterpreterRuntime::throw_pending_exception is tail-call optimized, >> the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR. >> It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build. > > Vladimir Kempik has updated the pull request incrementally with one additional commit since the last revision: > > Update the fix Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4115 From joe.darcy at oracle.com Thu May 20 15:48:00 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 20 May 2021 08:48:00 -0700 Subject: RFR: 8266530: HotSpot changes for JEP 306 [v7] In-Reply-To: References: Message-ID: <2c94d453-fa42-9634-1da3-09fd0561fc14@oracle.com> Hi David, Yes; this state of the changes reflects the final spec. Thanks, -Joe On 5/18/2021 7:45 PM, David Holmes wrote: > On Wed, 19 May 2021 00:30:10 GMT, Joe Darcy wrote: > >>> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >>> >>> JEP 306 is considering the following changes to the JVMS: >>> >>> 1) Require "strict" floating-point evaluation in all circumstances. >>> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >>> >>> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >>> >>> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >>> >>> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >>> >>> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >>> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >>> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: >> >> - Respond to review feedback. >> - Merge branch 'master' into 8266530 >> - Restore previous is_strict cdoe in method.hpp. >> - Merge branch 'master' into 8266530 >> - Make methods strict on IA32. >> - Merge branch 'master' into 8266530 >> - Merge branch 'master' into 8266530 >> - Respond to review feedback. >> - 8266530: HotSpot changes for JEP 306 > Latest update seems fine. > > Approving under the assumption these changes reflect the final spec. > > Thanks, > David > > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3891 From vkempik at openjdk.java.net Thu May 20 15:49:34 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Thu, 20 May 2021 15:49:34 GMT Subject: Integrated: 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash In-Reply-To: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> References: <1FPq4PQLO07EaTXAas6ntCN143bkvzEOA7WE4Kd1ygE=.816aeba3-e963-4445-a9ab-04cd8048ab5d@github.com> Message-ID: On Wed, 19 May 2021 12:54:03 GMT, Vladimir Kempik wrote: > Please review this patch for call_VM_Base routine. > it's expected there the LR is callee-saved register, but it's not on aarch64. > when InterpreterRuntime::throw_pending_exception is tail-call optimized, > the last subroutine before return is pthread_jit_write_protect_np which pac-sign LR. > It can only be reproduced in macos 11.4beta (just run J2Ddemo ) but in fact affects every aarch64 build. This pull request has now been integrated. Changeset: ca93399a Author: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/ca93399af103384e750dabf3abcc6e8392bcf3f4 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Reviewed-by: akozlov, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/4115 From ccheung at openjdk.java.net Thu May 20 17:12:01 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 20 May 2021 17:12:01 GMT Subject: RFR: 8267350: Archived old interface extends interface with default method causes crash Message-ID: During CDS dumping, an old class/interface won't be linked/rewritten. If an old interface extends an interface which contains a default method, the `_default_vtable_indices` will be updated during runtime. This small path is to make the `_default_vtable_indices` r/w during dump time for a class which hasn't been rewritten during dump time. Testing: - [x] mach5 tiers 1 - 4 (including the new test) ------------- Commit messages: - 8267350: Archived old interface extends interface with default method causes crash Changes: https://git.openjdk.java.net/jdk/pull/4132/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4132&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267350 Stats: 196 lines in 6 files changed: 195 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4132/head:pull/4132 PR: https://git.openjdk.java.net/jdk/pull/4132 From iklam at openjdk.java.net Thu May 20 17:43:34 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 20 May 2021 17:43:34 GMT Subject: RFR: 8267350: Archived old interface extends interface with default method causes crash In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:02:11 GMT, Calvin Cheung wrote: > During CDS dumping, an old class/interface won't be linked/rewritten. If an old interface extends an interface which contains a default method, the `_default_vtable_indices` will be updated during runtime. This small path is to make the `_default_vtable_indices` r/w during dump time for a class which hasn't been rewritten during dump time. > > Testing: > > - [x] mach5 tiers 1 - 4 (including the new test) LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4132 From hseigel at openjdk.java.net Thu May 20 18:25:10 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 20 May 2021 18:25:10 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v7] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:30:10 GMT, Joe Darcy wrote: >> Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. >> >> JEP 306 is considering the following changes to the JVMS: >> >> 1) Require "strict" floating-point evaluation in all circumstances. >> 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. >> >> Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. >> >> The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) >> >> FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. >> >> The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: >> * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. >> * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into 8266530 > - Restore previous is_strict cdoe in method.hpp. > - Merge branch 'master' into 8266530 > - Make methods strict on IA32. > - Merge branch 'master' into 8266530 > - Merge branch 'master' into 8266530 > - Respond to review feedback. > - 8266530: HotSpot changes for JEP 306 Changes look good. Thanks, Harold test/hotspot/jtreg/runtime/strictfp/StrictfpModifierChecksTest.java line 67: > 65: for (String version61ClassName : List.of("AbstractStrictfpMethod61", > 66: "AbstractStrictfpIntMethod61")) { > 67: // Same combination of modifiers is accpeted in class file version 61 minor typo: "accpeted" ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3891 From minqi at openjdk.java.net Thu May 20 19:58:31 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 20 May 2021 19:58:31 GMT Subject: RFR: 8267350: Archived old interface extends interface with default method causes crash In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:02:11 GMT, Calvin Cheung wrote: > During CDS dumping, an old class/interface won't be linked/rewritten. If an old interface extends an interface which contains a default method, the `_default_vtable_indices` will be updated during runtime. This small path is to make the `_default_vtable_indices` r/w during dump time for a class which hasn't been rewritten during dump time. > > Testing: > > - [x] mach5 tiers 1 - 4 (including the new test) LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4132 From darcy at openjdk.java.net Thu May 20 20:12:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 20 May 2021 20:12:06 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v8] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Fix typo found by @hseigel. - Merge branch 'master' into 8266530 - Respond to review feedback. - Merge branch 'master' into 8266530 - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Respond to review feedback. - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f2e689e9...62321229 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/2cdbd56b..62321229 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=06-07 Stats: 5833 lines in 299 files changed: 3660 ins; 1365 del; 808 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From ccheung at openjdk.java.net Thu May 20 20:31:28 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 20 May 2021 20:31:28 GMT Subject: RFR: 8267350: Archived old interface extends interface with default method causes crash In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:40:39 GMT, Ioi Lam wrote: >> During CDS dumping, an old class/interface won't be linked/rewritten. If an old interface extends an interface which contains a default method, the `_default_vtable_indices` will be updated during runtime. This small path is to make the `_default_vtable_indices` r/w during dump time for a class which hasn't been rewritten during dump time. >> >> Testing: >> >> - [x] mach5 tiers 1 - 4 (including the new test) > > LGTM @iklam, @yminqi Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4132 From ccheung at openjdk.java.net Thu May 20 21:05:45 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 20 May 2021 21:05:45 GMT Subject: Integrated: 8267350: Archived old interface extends interface with default method causes crash In-Reply-To: References: Message-ID: <1VMdrj4NL55bsNVLiiLKtAeqQWEwJjtZt4QbBf48_jA=.9e6c1f62-6e0d-4c31-8274-6503d0dcfdd4@github.com> On Thu, 20 May 2021 17:02:11 GMT, Calvin Cheung wrote: > During CDS dumping, an old class/interface won't be linked/rewritten. If an old interface extends an interface which contains a default method, the `_default_vtable_indices` will be updated during runtime. This small path is to make the `_default_vtable_indices` r/w during dump time for a class which hasn't been rewritten during dump time. > > Testing: > > - [x] mach5 tiers 1 - 4 (including the new test) This pull request has now been integrated. Changeset: 1c7a1310 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/1c7a1310d9985fd0ad05d901186eb0b6c0045d74 Stats: 196 lines in 6 files changed: 195 ins; 0 del; 1 mod 8267350: Archived old interface extends interface with default method causes crash Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4132 From dholmes at openjdk.java.net Thu May 20 22:09:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 22:09:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 11:42:06 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Updates mostly good but still a storestore issue to resolve. Thanks, David src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379: > 377: ret = simple_wait(self, millis); > 378: > 379: // Now we need to re-enter the monitor. For JavaThread's My bad: no apostrophe in JavaThreads src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > 210: _thread->frame_anchor()->make_walkable(_thread); > 211: OrderAccess::storestore(); > 212: _thread->set_thread_state(_thread_in_native); Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From vlivanov at openjdk.java.net Thu May 20 22:22:49 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 20 May 2021 22:22:49 GMT Subject: RFR: 8266642: improve ResolvedMethodTable hash function [v9] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:39:04 GMT, Denghui Dong wrote: >> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. >> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > remote LogMinObjAlignmentInBytes Tier1-tier2 results are good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From ddong at openjdk.java.net Thu May 20 22:22:50 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 20 May 2021 22:22:50 GMT Subject: Integrated: 8266642: improve ResolvedMethodTable hash function In-Reply-To: References: Message-ID: <4f-aYFXRn2WAlgV1B1Y_UBf4HIs7qaGyqBzdeDyjwbM=.1a67a05b-f5c8-4a44-85bf-8d426547fb44@github.com> On Thu, 6 May 2021 14:25:40 GMT, Denghui Dong wrote: > JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name. > Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem. This pull request has now been integrated. Changeset: 83b36072 Author: Denghui Dong Committer: Vladimir Ivanov URL: https://git.openjdk.java.net/jdk/commit/83b360729060abaefb00a0b3f6165926db956bf8 Stats: 21 lines in 3 files changed: 19 ins; 0 del; 2 mod 8266642: improve ResolvedMethodTable hash function Reviewed-by: vlivanov, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3901 From dholmes at openjdk.java.net Fri May 21 02:22:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 21 May 2021 02:22:37 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > lir_div_strictfp and lir_mul_strictfp Can I please get re-reviews for this. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From jiefu at openjdk.java.net Fri May 21 05:21:49 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 05:21:49 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError Message-ID: Hi all, vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. However, the expected OOME in metaspace was caught this time. But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. So both -Xmx and -XX:MetaspaceSize should be increased. The fix just: - Revert changes about mataspace size setting - Increase -Xmx from 256m to 1g -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. Thanks. Best regards, Jie ------------- Commit messages: - Unproblemlist vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java - 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError Changes: https://git.openjdk.java.net/jdk/pull/4140/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4140&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267404 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4140/head:pull/4140 PR: https://git.openjdk.java.net/jdk/pull/4140 From stefank at openjdk.java.net Fri May 21 08:46:27 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 21 May 2021 08:46:27 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 05:11:51 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. > The reason is that both -Xmx and -XX:MetaspaceSize are not enough. > > From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. > > Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. > However, the expected OOME in metaspace was caught this time. > But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. > > So both -Xmx and -XX:MetaspaceSize should be increased. > The fix just: > - Revert changes about mataspace size setting > - Increase -Xmx from 256m to 1g > > -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. > > Thanks. > Best regards, > Jie Maybe this is already understood, but in case it is not clear: -XX:MetaspaceSize is only used to determine at what point the first metaspace-induced GC should happen. When the Metaspace is filled up to that value, we trigger a GC. It is -XX:MaxMetaspaceSize that is the limit of how much memory we may commit for the metaspace. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From rehn at openjdk.java.net Fri May 21 08:49:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 21 May 2021 08:49:43 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 21:51:31 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Review fixes 2 >> - Merge branch 'master' into 8265753 >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379: > >> 377: ret = simple_wait(self, millis); >> 378: >> 379: // Now we need to re-enter the monitor. For JavaThread's > > My bad: no apostrophe in JavaThreads Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > >> 210: _thread->frame_anchor()->make_walkable(_thread); >> 211: OrderAccess::storestore(); >> 212: _thread->set_thread_state(_thread_in_native); > > Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? > But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. But we have more of those. Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). So yes it should always be there, good RFE! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From jiefu at openjdk.java.net Fri May 21 09:01:35 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 09:01:35 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:44:02 GMT, Stefan Karlsson wrote: > Maybe this is already understood, but in case it is not clear: -XX:MetaspaceSize is only used to determine at what point the first metaspace-induced GC should happen. When the Metaspace is filled up to that value, we trigger a GC. It is -XX:MaxMetaspaceSize that is the limit of how much memory we may commit for the metaspace. Got it. Thanks @stefank for your clarification. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From stuefe at openjdk.java.net Fri May 21 09:28:34 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 21 May 2021 09:28:34 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:58:47 GMT, Jie Fu wrote: > Maybe this is already understood, but in case it is not clear: -XX:MetaspaceSize is only used to determine at what point the first metaspace-induced GC should happen. When the Metaspace is filled up to that value, we trigger a GC. It is -XX:MaxMetaspaceSize that is the limit of how much memory we may commit for the metaspace. Arguably MetaspaceSize=MaxMetaspaceSize helps a tiny tiny bit in lowering the runtime for this test, since we avoid some GC cycles (which would not collect anything anyway since this test does not unload anything). ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From rehn at openjdk.java.net Fri May 21 09:41:10 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 21 May 2021 09:41:10 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Final fixes: last famous words ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/6faf1422..cc15431e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=04-05 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From stuefe at openjdk.java.net Fri May 21 10:03:29 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 21 May 2021 10:03:29 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 05:11:51 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. > The reason is that both -Xmx and -XX:MetaspaceSize are not enough. > > From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. > > Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. > However, the expected OOME in metaspace was caught this time. > But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. > > So both -Xmx and -XX:MetaspaceSize should be increased. > The fix just: > - Revert changes about mataspace size setting > - Increase -Xmx from 256m to 1g > > -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. > > Thanks. > Best regards, > Jie I don't think this patch does what you think it does, sorry. First off, as @stefank said, please forget about `MetaspaceSize` (terribly confusing name). Either omit it or set it to the same value as `MaxMetaspaceSize`. The latter may cause the test to be slightly faster, but it does not matter much either way. The test allocates classes endlessly. The point of this test is to fill up metaspace with data until it is full, then to observe a correctly thrown OOM from Metaspace. For that to work, metaspace has to be **small**, not large. In theory you could make it as small as 512k or so. Only, we need the VM itself to come up and start the test. So the VM needs to be able to load all JDK classes needed for booting, then the test classes. Then the test starts, loads all these generated classes, and then metaspace should run out. In my local tests I was able to run the test correctly with MaxMetaspaceSize=4m. Each generated j.l.Class object needs heap space too, therefore this test is a race between what part is exhausted earlier, metaspace or heap. If you see an OOM from heap, not metaspace, it means heap space ran out first, and the test will fail. You want metaspace to be as small as possible, heap space to be large enough to exhaust metaspace first. In my local test on Linux x64, I was able to run with MaxMetaspaceSize=4m and 128m heap space. If you increase MaxMetaspaceSize to 20m, you will clearly need more and more heap space to still be able to exhaust that higher limit. Leave MaxMetaspaceSize at 8, or preferably less. What I am concerned about is that with there should not be *that* much variance in how much heap space we use. Sure you can set it to 1g or 2g, but something is clearly off. I get by on Linux x64 with 128m, on 32bit x86 with 256m (since we don't have CompressedClassPointers we need somewhat more heap). But needing 1g on aarch64 seems weird. Cheers, Thomas p.s. One source of variance may be the question if CDS is on or off. If CDS is on (default), the JVM will use significantly less Metaspace at boot. With CDS off, we use more metaspace. It may make sense to set Xshare=off to get rid of this variance. p.p.s. There are several ways to improve this test and make it more robust: 1) increase the class size (see AnonkTestee01 - make a sister class with more fields and more constants and use that one) 2) Rewrite the whole test: let it start a jvm with ProcessBuilder with a very low metaspace - too low to load the JDK itself. Something like this: `java -Xshare:off -XX:MaxMetaspaceSize=1m -version`. The VM should not come up; instead we should see an `OutOfMemoryError: Metaspace` at stdout. (1) makes the test run through faster and requires less heap to fill up metaspace (2) would completely remove the guessing game of "how much metaspace do I need to let the VM come up and start the test". ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From rehn at openjdk.java.net Fri May 21 10:35:37 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 21 May 2021 10:35:37 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake In-Reply-To: <3jFXzMxaxGPL_Tbc-PbJJHG6wH0FLqm_Po4_DNw0p0c=.19a7a073-9db9-4635-b310-05c331dd280a@github.com> References: <3jFXzMxaxGPL_Tbc-PbJJHG6wH0FLqm_Po4_DNw0p0c=.19a7a073-9db9-4635-b310-05c331dd280a@github.com> Message-ID: On Tue, 18 May 2021 09:26:11 GMT, Yude Lin wrote: >> We can just remove this: >> >> if (i != 0 && thread->is_Java_thread()) { >> JavaThread* jt = thread->as_Java_thread(); >> if (jt->thread_state() == _thread_in_vm) { >> // Since this JavaThread has looped at least once and is _thread_in_vm, >> // we honor any pending blocking request. >> ThreadBlockInVM tbivm(jt); >> } >> } >> >> >> >> Under some wired circumstances it can prolong TTS. >> But it was me that found it. Reverting it wouldn't get any complains from anyone else. >> >> (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) > >> We can just remove this: >> >> if (i != 0 && thread->is_Java_thread()) { >> JavaThread* jt = thread->as_Java_thread(); >> if (jt->thread_state() == _thread_in_vm) { >> // Since this JavaThread has looped at least once and is _thread_in_vm, >> // we honor any pending blocking request. >> ThreadBlockInVM tbivm(jt); >> } >> } >> >> Under some wired circumstances it can prolong TTS. >> But it was me that found it. Reverting it wouldn't get any complains from anyone else. >> >> (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) > > In that case this is a solution I can get behind. > >> The issue is that inside the handshake closure you would transition to >> the blocked state in ThreadBlockInVM(), which allows a safepoint to >> proceed. If in ~ThreadBlockInVM() we don't stop for the safepoint and >> just return in SafepointMechanism::process_if_requested_slow() then now >> you would have a safepoint and handshake executing at the same time. > > Ah I see, there I was thinking a thread is only considered in safepoint by VM Thread when it's blocked in SafepointMechanism::process, but it actually happen when transitioned to the _thread_blocked state. Thanks for pointing it out! @linade will you re-do the PR with that change instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From jiefu at openjdk.java.net Fri May 21 11:41:33 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 11:41:33 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 09:59:18 GMT, Thomas Stuefe wrote: > 2. Rewrite the whole test: let it start a jvm with ProcessBuilder with a very low metaspace - too low to load the JDK itself. Something like this: `java -Xshare:off -XX:MaxMetaspaceSize=1m -version`. The VM should not come up; instead we should see an `OutOfMemoryError: Metaspace` at stdout. Thanks @tstuefe for your nice analysis. Much has been learned from you all today. Due to the race between heap and metaspace, I prefer the second approach (rewrite the whole test with ProcessBuilder). Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Fri May 21 14:01:13 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 14:01:13 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v2] In-Reply-To: References: Message-ID: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. > The reason is that both -Xmx and -XX:MetaspaceSize are not enough. > > From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. > > Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. > However, the expected OOME in metaspace was caught this time. > But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. > > So both -Xmx and -XX:MetaspaceSize should be increased. > The fix just: > - Revert changes about mataspace size setting > - Increase -Xmx from 256m to 1g > > -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Rewrite the test with ProcessBuilder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4140/files - new: https://git.openjdk.java.net/jdk/pull/4140/files/488cdb62..87791076 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4140&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4140&range=00-01 Stats: 49 lines in 1 file changed: 0 ins; 31 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4140/head:pull/4140 PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Fri May 21 14:01:55 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 14:01:55 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 11:38:21 GMT, Jie Fu wrote: > 2. Rewrite the whole test: let it start a jvm with ProcessBuilder with a very low metaspace - too low to load the JDK itself. Something like this: `java -Xshare:off -XX:MaxMetaspaceSize=1m -version`. The VM should not come up; instead we should see an `OutOfMemoryError: Metaspace` at stdout. Hi @tstuefe , The test has been rewrite with ProcessBuilder. Please review it. Testing: - The affected test on Linux/x86_{64, 32}, MacOSX Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From stuefe at openjdk.java.net Fri May 21 14:44:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 21 May 2021 14:44:08 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:01:13 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Rewrite the test with ProcessBuilder Seems fine. I can confirm this working with x86 and x64. The MaxMetaspaceSize feels a bit on the low side - I would prefer a somewhat increased value of maybe 512k or 1m. Just to get the VM rolling a bit before OOMing out. I tested 1m for both 32bit and 64bit, seems to work too. But I leave it up to you, this is fine too. Just please make sure other platforms work with this setting, esp. arm32 and aarch64. (I'm on vacation and won't be able to look at this for the next two weeks). If nobody uses AnonkTestee01 anymore, that class can be removed. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Fri May 21 15:19:17 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 15:19:17 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: Message-ID: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. > The reason is that both -Xmx and -XX:MetaspaceSize are not enough. > > From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. > > Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. > However, the expected OOME in metaspace was caught this time. > But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. > > So both -Xmx and -XX:MetaspaceSize should be increased. > The fix just: > - Revert changes about mataspace size setting > - Increase -Xmx from 256m to 1g > > -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Increase MaxMetaspaceSize to 512k ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4140/files - new: https://git.openjdk.java.net/jdk/pull/4140/files/87791076..b8df6e06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4140&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4140&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4140.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4140/head:pull/4140 PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Fri May 21 15:25:09 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 15:25:09 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:40:52 GMT, Thomas Stuefe wrote: > Seems fine. I can confirm this working with x86 and x64. > > The MaxMetaspaceSize feels a bit on the low side - I would prefer a somewhat increased value of maybe 512k or 1m. Just to get the VM rolling a bit before OOMing out. I tested 1m for both 32bit and 64bit, seems to work too. > > But I leave it up to you, this is fine too. Just please make sure other platforms work with this setting, esp. arm32 and aarch64. > > (I'm on vacation and won't be able to look at this for the next two weeks). > > If nobody uses AnonkTestee01 anymore, that class can be removed. > > Cheers, Thomas Thanks @tstuefe for your review. MaxMetaspaceSize has been increased to 512k. It works on our Linux/{x86, x64}, MacOSX and aarch64. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Fri May 21 15:28:58 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 15:28:58 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 15:22:09 GMT, Jie Fu wrote: > If nobody uses AnonkTestee01 anymore, that class can be removed. I'll check if we can remove it safely next week. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From dcubed at openjdk.java.net Fri May 21 15:45:25 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 21 May 2021 15:45:25 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic Message-ID: A pair of trivial fixes for a couple of ObjectMonitor cleanups. Tested with Mach5 Tier[1-3]. ------------- Commit messages: - 8256301: ObjectMonitor::is_busy() should return bool - 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic Changes: https://git.openjdk.java.net/jdk/pull/4137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256304 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4137/head:pull/4137 PR: https://git.openjdk.java.net/jdk/pull/4137 From coleenp at openjdk.java.net Fri May 21 16:46:02 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 21 May 2021 16:46:02 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: <9CY46yqmbgVz8_UzcWQAk-jYtroU3_9mWLBxoM1uMD0=.21f5cc30-d41d-4442-8750-94bc8e9e5661@github.com> On Thu, 20 May 2021 22:21:03 GMT, Daniel D. Daugherty wrote: > A pair of trivial fixes for a couple of ObjectMonitor cleanups. > > Tested with Mach5 Tier[1-3]. Thank you! Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4137 From vlivanov at openjdk.java.net Fri May 21 18:03:57 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 21 May 2021 18:03:57 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > lir_div_strictfp and lir_mul_strictfp Marked as reviewed by vlivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From iklam at openjdk.java.net Fri May 21 18:16:16 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 21 May 2021 18:16:16 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class Message-ID: In CDS terms, "Unregistered classes" are the archived classes that should be loaded by custom class loaders during runtime. Archiving of class loader constraints ([JDK-8178349](https://bugs.openjdk.java.net/browse/JDK-8178349)) should be disabled for such classes. During CDS dump time (-Xshare:dump), unregistered classes are loaded by the boot loader (see also [JDK-8261941](https://bugs.openjdk.java.net/browse/JDK-8261941)). `SystemDictionaryShared::record_linking_constraint` doesn't properly recognize such classes, leading to the assert. ------------- Commit messages: - fixed windows testing - 8267347: CDS record_linking_constraint asserts with unregistered class Changes: https://git.openjdk.java.net/jdk/pull/4147/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4147&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267347 Stats: 161 lines in 5 files changed: 138 ins; 4 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4147.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4147/head:pull/4147 PR: https://git.openjdk.java.net/jdk/pull/4147 From vlivanov at openjdk.java.net Fri May 21 18:19:00 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 21 May 2021 18:19:00 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > lir_div_strictfp and lir_mul_strictfp There are some suspicious failures on linux-x86 in pre-submit testing results: - compiler/c1/Test6855215.java - compiler/intrinsics/string/TestStringLatin1IndexOfChar.java The tests explicitly specify `-XX:UseSSE=0`, so it may be related to the patch. Anybody interested in linux-x86 want to take a look? @shade @DamonFool ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From dcubed at openjdk.java.net Fri May 21 18:22:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 21 May 2021 18:22:58 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: <9CY46yqmbgVz8_UzcWQAk-jYtroU3_9mWLBxoM1uMD0=.21f5cc30-d41d-4442-8750-94bc8e9e5661@github.com> References: <9CY46yqmbgVz8_UzcWQAk-jYtroU3_9mWLBxoM1uMD0=.21f5cc30-d41d-4442-8750-94bc8e9e5661@github.com> Message-ID: On Fri, 21 May 2021 16:43:11 GMT, Coleen Phillimore wrote: >> A pair of trivial fixes for a couple of ObjectMonitor cleanups. >> >> Tested with Mach5 Tier[1-3]. > > Thank you! Looks good! @coleenp - Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From dcubed at openjdk.java.net Fri May 21 18:32:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 21 May 2021 18:32:59 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:26:14 GMT, Patricio Chilano Mateo wrote: >> A pair of trivial fixes for a couple of ObjectMonitor cleanups. >> >> Tested with Mach5 Tier[1-3]. > > Looks good to me! @pchilano - Thanks for the review! Do you agree this is trivial? (I don't want to wait 24 hours...) ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From pchilanomate at openjdk.java.net Fri May 21 18:32:59 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 21 May 2021 18:32:59 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Thu, 20 May 2021 22:21:03 GMT, Daniel D. Daugherty wrote: > A pair of trivial fixes for a couple of ObjectMonitor cleanups. > > Tested with Mach5 Tier[1-3]. Looks good to me! ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/4137 From coleenp at openjdk.java.net Fri May 21 18:33:00 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 21 May 2021 18:33:00 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Thu, 20 May 2021 22:21:03 GMT, Daniel D. Daugherty wrote: > A pair of trivial fixes for a couple of ObjectMonitor cleanups. > > Tested with Mach5 Tier[1-3]. Yes, I agree it's trivial also. ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From pchilanomate at openjdk.java.net Fri May 21 18:33:00 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 21 May 2021 18:33:00 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:26:14 GMT, Patricio Chilano Mateo wrote: >> A pair of trivial fixes for a couple of ObjectMonitor cleanups. >> >> Tested with Mach5 Tier[1-3]. > > Looks good to me! > @pchilano - Thanks for the review! > Do you agree this is trivial? (I don't want to wait 24 hours...) Yes, I agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From dcubed at openjdk.java.net Fri May 21 18:33:00 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 21 May 2021 18:33:00 GMT Subject: RFR: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:29:40 GMT, Coleen Phillimore wrote: >> A pair of trivial fixes for a couple of ObjectMonitor cleanups. >> >> Tested with Mach5 Tier[1-3]. > > Yes, I agree it's trivial also. @coleenp and @pchilano - Thanks for the reviews and for concurrence on the triviality of this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From dcubed at openjdk.java.net Fri May 21 18:36:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 21 May 2021 18:36:09 GMT Subject: Integrated: 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic In-Reply-To: References: Message-ID: On Thu, 20 May 2021 22:21:03 GMT, Daniel D. Daugherty wrote: > A pair of trivial fixes for a couple of ObjectMonitor cleanups. > > Tested with Mach5 Tier[1-3]. This pull request has now been integrated. Changeset: fe333431 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/fe333431c8c0f089e4fd55bf10903e1fba7fc6c4 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod 8256304: should MonitorUsedDeflationThreshold be experimental or diagnostic 8256301: ObjectMonitor::is_busy() should return bool Reviewed-by: coleenp, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/4137 From minqi at openjdk.java.net Fri May 21 19:09:58 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 21 May 2021 19:09:58 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class In-Reply-To: References: Message-ID: On Fri, 21 May 2021 17:58:25 GMT, Ioi Lam wrote: > In CDS terms, "Unregistered classes" are the archived classes that should be loaded by custom class loaders during runtime. Archiving of class loader constraints ([JDK-8178349](https://bugs.openjdk.java.net/browse/JDK-8178349)) should be disabled for such classes. > > During CDS dump time (-Xshare:dump), unregistered classes are loaded by the boot loader (see also [JDK-8261941](https://bugs.openjdk.java.net/browse/JDK-8261941)). `SystemDictionaryShared::record_linking_constraint` doesn't properly recognize such classes, leading to the assert. LGTM. test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 104: > 102: String testCase = Integer.toString(i); > 103: String cmdLine[] = new String[] { > 104: "--add-modules", Here is not aligned with below. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4147 From ccheung at openjdk.java.net Fri May 21 21:42:59 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 21 May 2021 21:42:59 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class In-Reply-To: References: Message-ID: On Fri, 21 May 2021 17:58:25 GMT, Ioi Lam wrote: > In CDS terms, "Unregistered classes" are the archived classes that should be loaded by custom class loaders during runtime. Archiving of class loader constraints ([JDK-8178349](https://bugs.openjdk.java.net/browse/JDK-8178349)) should be disabled for such classes. > > During CDS dump time (-Xshare:dump), unregistered classes are loaded by the boot loader (see also [JDK-8261941](https://bugs.openjdk.java.net/browse/JDK-8261941)). `SystemDictionaryShared::record_linking_constraint` doesn't properly recognize such classes, leading to the assert. Looks good. Just one question and one nit. test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 52: > 50: httpHandlerClass, > 51: httpExchangeClass, > 52: Asserts.class.getName(), Why other class names don't need to do `replace(".", "/")`? test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java line 32: > 30: > 31: // This is a handy class for running an application inside a custom class loader. This > 32: // is used for testing CDS handling of unregistered classes (i.e., archved classes loaded Typo: archved -> archived ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4147 From jiefu at openjdk.java.net Fri May 21 23:08:00 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 21 May 2021 23:08:00 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Fri, 21 May 2021 15:19:17 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Increase MaxMetaspaceSize to 512k According to @dcubed-ojdk 's comments in the JBS, the latest change passed in Oracle's CI/CD. Will push it tomorrow if there is no objection. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From kvn at openjdk.java.net Fri May 21 23:25:56 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 21 May 2021 23:25:56 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > lir_div_strictfp and lir_mul_strictfp Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From jiefu at openjdk.java.net Sat May 22 00:02:05 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 22 May 2021 00:02:05 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: <8UuamCdBlg8NiUW9iCluoNTLJAxbgeS38y3C_50ZWyA=.ae70148a-c8cf-4b65-bb3b-ce1f095ea455@github.com> On Fri, 21 May 2021 18:16:23 GMT, Vladimir Ivanov wrote: > There are some suspicious failures on linux-x86 in pre-submit testing results: > > * compiler/c1/Test6855215.java > * compiler/intrinsics/string/TestStringLatin1IndexOfChar.java > > The tests explicitly specify `-XX:UseSSE=0`, so it may be related to the patch. Anybody interested in linux-x86 want to take a look? @shade @DamonFool compiler/c1/Test6855215.java crashes on x86_32 with the latest patch. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/jdk/src/hotspot/cpu/x86/c1_LinearScan_x86.cpp:683), pid=13254, tid=13270 # assert(op2->tmp1_opr()->is_fpu_register()) failed: strict operations need temporary fpu stack slot # # JRE version: OpenJDK Runtime Environment (17.0) (fastdebug build 17-internal+0-adhoc..jdk) # Java VM: OpenJDK Server VM (fastdebug 17-internal+0-adhoc..jdk, mixed mode, sharing, tiered, g1 gc, linux-x86) # Problematic frame: # V [libjvm.so+0x64fcf0] FpuStackAllocator::handle_op2(LIR_Op2*)+0x120 # Current CompileTask: C1: 109 66 b 3 java.util.HashMap::resize (356 bytes) Stack: [0xa1f7f000,0xa2000000], sp=0xa1ffe540, free space=509k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x64fcf0] FpuStackAllocator::handle_op2(LIR_Op2*)+0x120 V [libjvm.so+0x65232c] FpuStackAllocator::allocate_block(BlockBegin*)+0x28c V [libjvm.so+0x6526af] FpuStackAllocator::allocate()+0xcf V [libjvm.so+0x652a4d] LinearScan::allocate_fpu_stack()+0xcd V [libjvm.so+0x648d7a] LinearScan::do_linear_scan()+0x39a V [libjvm.so+0x588f40] Compilation::emit_lir()+0xd10 V [libjvm.so+0x58ba60] Compilation::compile_java_method()+0x720 V [libjvm.so+0x58c287] Compilation::compile_method()+0x247 V [libjvm.so+0x58cbe3] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x3d3 V [libjvm.so+0x58de72] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1b2 V [libjvm.so+0x83f5fb] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc6b V [libjvm.so+0x83ff71] CompileBroker::compiler_thread_loop()+0x491 V [libjvm.so+0x86b8c6] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x56 V [libjvm.so+0x14b28e2] JavaThread::thread_main_inner()+0x242 V [libjvm.so+0x14b794a] Thread::call_run()+0xfa V [libjvm.so+0x10fc9bf] thread_native_entry(Thread*)+0x11f C [libpthread.so.0+0x63bd] start_thread+0xfd compiler/intrinsics/string/TestStringLatin1IndexOfChar.java seems fine on my x86_32. I didn't take a further look at the crash since it's already weekend now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From david.holmes at oracle.com Sat May 22 02:15:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 May 2021 12:15:34 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: <3ba8220c-e21d-7bc3-9a7a-942c424af374@oracle.com> Hi Vladimir, On 22/05/2021 4:19 am, Vladimir Ivanov wrote: > On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: > >>> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >>> >>> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> lir_div_strictfp and lir_mul_strictfp > > There are some suspicious failures on linux-x86 in pre-submit testing results: > - compiler/c1/Test6855215.java > - compiler/intrinsics/string/TestStringLatin1IndexOfChar.java > > The tests explicitly specify `-XX:UseSSE=0`, so it may be related to the patch. Anybody interested in linux-x86 want to take a look? @shade @DamonFool I'll take a look at the patch again because it is supposed to involve no functional changes. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From david.holmes at oracle.com Sat May 22 02:25:16 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 May 2021 12:25:16 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: <3ba8220c-e21d-7bc3-9a7a-942c424af374@oracle.com> References: <3ba8220c-e21d-7bc3-9a7a-942c424af374@oracle.com> Message-ID: <7949a2bf-a26d-16c9-ce00-f514dc21edc2@oracle.com> Correction ... On 22/05/2021 12:15 pm, David Holmes wrote: > Hi Vladimir, > > On 22/05/2021 4:19 am, Vladimir Ivanov wrote: >> On Tue, 18 May 2021 04:26:00 GMT, David Holmes >> wrote: >> >>>> As part of JEP 306, the vestiges of HotSpot support for non-strict >>>> floating-point execution can be removed. All methods implicitly have >>>> strictfp semantics so the explicit checks for is_strict() can be >>>> replaced by true and the code reformulated accordingly. >>>> >>>> There are still some names that include "strict" that could >>>> potentially be renamed to remove it, but the fact we have to have >>>> strict fp semantics is still important on some platforms, so the >>>> names help reinforce that IMO. >>>> >>>> Testing: tiers 1-3 >>>> >>>> Thanks, >>>> David >>> >>> David Holmes has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? lir_div_strictfp and lir_mul_strictfp >> >> There are some suspicious failures on linux-x86 in pre-submit testing >> results: >> - compiler/c1/Test6855215.java >> - compiler/intrinsics/string/TestStringLatin1IndexOfChar.java >> >> The tests explicitly specify `-XX:UseSSE=0`, so it may be related to >> the patch. Anybody interested in linux-x86 want to take a look? @shade >> @DamonFool > > I'll take a look at the patch again because it is supposed to involve no > functional changes. That isn't actually true. We are now forcing 32-bit x86 to always have strict semantics, where previously they could use non-strict. David > Thanks, > David > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/3991 >> From stuefe at openjdk.java.net Sat May 22 04:59:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 22 May 2021 04:59:08 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: Message-ID: On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews for this very simple change (triggered by this ML discussion [1]): > > On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake. > > The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake. > > I ran OPs [1] test on my machine and with logging to a very fast ssd enabled: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 5191 > > > with this patch test time drops by about 19%: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 4228 > > > No perceptible difference with logging disabled, as it should be. > > --- > > (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.) > > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html Ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/4042 From vlivanov at openjdk.java.net Sat May 22 13:51:57 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Sat, 22 May 2021 13:51:57 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > lir_div_strictfp and lir_mul_strictfp Thanks, Jie. I think there's `result->is_double_fpu()` check missing in `FpuStackAllocator::handle_op2`: case lir_mul: case lir_div: { assert(op2->tmp1_opr()->is_fpu_register(), "strict operations need temporary fpu stack slot"); insert_free_if_dead(op2->tmp1_opr()); assert(sim()->stack_size() <= 7, "at least one stack slot must be free"); // fall-through: continue with the normal handling of lir_mul and lir_div } The code should be guarded by `result->is_double_fpu()` since special handling (additional temp operand) is needed only for `mul`/`div` on doubles. src/hotspot/share/c1/c1_GraphBuilder.cpp line 1126: > 1124: Value y = pop(type); > 1125: Value x = pop(type); > 1126: Value res = new ArithmeticOp(code, x, y,state_before); Please, put a space before `state_before`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From jiefu at openjdk.java.net Sat May 22 23:03:02 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 22 May 2021 23:03:02 GMT Subject: Integrated: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError In-Reply-To: References: Message-ID: On Fri, 21 May 2021 05:11:51 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. > The reason is that both -Xmx and -XX:MetaspaceSize are not enough. > > From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. > > Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. > However, the expected OOME in metaspace was caught this time. > But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. > > So both -Xmx and -XX:MetaspaceSize should be increased. > The fix just: > - Revert changes about mataspace size setting > - Increase -Xmx from 256m to 1g > > -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 6288a993 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/6288a9936cc7e69cab0cc5f3e49c803f184bf2ca Stats: 50 lines in 2 files changed: 0 ins; 32 del; 18 mod 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError Co-authored-by: xiangyuan Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From david.holmes at oracle.com Sun May 23 00:02:41 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 May 2021 10:02:41 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: On 22/05/2021 11:51 pm, Vladimir Ivanov wrote: > On Tue, 18 May 2021 04:26:00 GMT, David Holmes wrote: > >>> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >>> >>> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >>> >>> Testing: tiers 1-3 >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> lir_div_strictfp and lir_mul_strictfp > > Thanks, Jie. > > I think there's `result->is_double_fpu()` check missing in `FpuStackAllocator::handle_op2`: > > case lir_mul: > case lir_div: { > assert(op2->tmp1_opr()->is_fpu_register(), "strict operations need temporary fpu stack slot"); > insert_free_if_dead(op2->tmp1_opr()); > assert(sim()->stack_size() <= 7, "at least one stack slot must be free"); > // fall-through: continue with the normal handling of lir_mul and lir_div > } > > The code should be guarded by `result->is_double_fpu()` since special handling (additional temp operand) is needed only for `mul`/`div` on doubles. Where was that guard on the existing strict version? This failure is suggesting to me that there may be a pre-existing bug in the strict/non-strict code on x86. I need to check exactly what cases the failing test is failing on so that I can see which code change is in play. I have a suspicion but can't check it yet. > src/hotspot/share/c1/c1_GraphBuilder.cpp line 1126: > >> 1124: Value y = pop(type); >> 1125: Value x = pop(type); >> 1126: Value res = new ArithmeticOp(code, x, y,state_before); > > Please, put a space before `state_before`. Will do. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From dholmes at openjdk.java.net Sun May 23 00:09:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 23 May 2021 00:09:20 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v3] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Add missing space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/c0c35a77..3ddd6330 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From vladimir.x.ivanov at oracle.com Sun May 23 14:13:10 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sun, 23 May 2021 17:13:10 +0300 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: References: Message-ID: <9f7d558e-8d2d-67d1-a19c-f0c0df7ab3a5@oracle.com> >> I think there's `result->is_double_fpu()` check missing in >> `FpuStackAllocator::handle_op2`: >> >> ????? case lir_mul: >> ????? case lir_div: { >> ??????? assert(op2->tmp1_opr()->is_fpu_register(), "strict operations >> need temporary fpu stack slot"); >> ??????? insert_free_if_dead(op2->tmp1_opr()); >> ??????? assert(sim()->stack_size() <= 7, "at least one stack slot must >> be free"); >> ??????? // fall-through: continue with the normal handling of lir_mul >> and lir_div >> ????? } >> >> The code should be guarded by `result->is_double_fpu()` since special >> handling (additional temp operand) is needed only for `mul`/`div` on >> doubles. > > Where was that guard on the existing strict version? > > This failure is suggesting to me that there may be a pre-existing bug in > the strict/non-strict code on x86. I need to check exactly what cases > the failing test is failing on so that I can see which code change is in > play. I have a suspicion but can't check it yet. The guard was implicit: `lir_mul_strict`/`lir_div_strict` operations were always instantiated with the temp FPU operand. Since they are removed now, there's aliasing occurring between `lir_mul`/`lir_div` on doubles (`lir_mul_strict`/`lir_div_strict` before) and original operations on ints/longs/floats. So, the check has to be explicit now. Only ddiv/dmul implementations need a temp operand. Best regards, Vladimir Ivanov From david.holmes at oracle.com Sun May 23 22:59:09 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 May 2021 08:59:09 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2] In-Reply-To: <9f7d558e-8d2d-67d1-a19c-f0c0df7ab3a5@oracle.com> References: <9f7d558e-8d2d-67d1-a19c-f0c0df7ab3a5@oracle.com> Message-ID: <0e418bab-893f-f4b8-243b-b4e84a621cbb@oracle.com> On 24/05/2021 12:13 am, Vladimir Ivanov wrote: >>> I think there's `result->is_double_fpu()` check missing in >>> `FpuStackAllocator::handle_op2`: >>> >>> ????? case lir_mul: >>> ????? case lir_div: { >>> ??????? assert(op2->tmp1_opr()->is_fpu_register(), "strict operations >>> need temporary fpu stack slot"); >>> ??????? insert_free_if_dead(op2->tmp1_opr()); >>> ??????? assert(sim()->stack_size() <= 7, "at least one stack slot >>> must be free"); >>> ??????? // fall-through: continue with the normal handling of lir_mul >>> and lir_div >>> ????? } >>> >>> The code should be guarded by `result->is_double_fpu()` since special >>> handling (additional temp operand) is needed only for `mul`/`div` on >>> doubles. >> >> Where was that guard on the existing strict version? >> >> This failure is suggesting to me that there may be a pre-existing bug >> in the strict/non-strict code on x86. I need to check exactly what >> cases the failing test is failing on so that I can see which code >> change is in play. I have a suspicion but can't check it yet. > > The guard was implicit: `lir_mul_strict`/`lir_div_strict` operations > were always instantiated with the temp FPU operand. Since they are > removed now, there's aliasing occurring between `lir_mul`/`lir_div` on > doubles (`lir_mul_strict`/`lir_div_strict` before) and original > operations on ints/longs/floats. Right I just tracked that through before seeing this email. The fmul uses the non-tmp version but later all lir_mul are assumed the same. Thanks, David > So, the check has to be explicit now. Only ddiv/dmul implementations > need a temp operand. > > Best regards, > Vladimir Ivanov From dholmes at openjdk.java.net Sun May 23 23:09:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 23 May 2021 23:09:39 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v4] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: The code for strict handling only applies to doubles. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/3ddd6330..89e90058 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From dholmes at openjdk.java.net Sun May 23 23:14:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 23 May 2021 23:14:08 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v5] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into jep-306 - The code for strict handling only applies to doubles. - Add missing space - lir_div_strictfp and lir_mul_strictfp - Removed divDPR_reg_round as it has a false predicate and so is now unused - Revert classFileParser changes as they will be handled by JDK-8266530 - 8266530: HotSpot changes for JEP 306 All methods are now implicitly strictfp so all code generation etc uses the strict form. There are still some names that include "strict" that could potentially be renamed to rmeove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/89e90058..4dcab9b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=03-04 Stats: 29911 lines in 904 files changed: 14007 ins; 12146 del; 3758 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From jiefu at openjdk.java.net Sun May 23 23:42:14 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 23 May 2021 23:42:14 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: <0e418bab-893f-f4b8-243b-b4e84a621cbb@oracle.com> References: <0e418bab-893f-f4b8-243b-b4e84a621cbb@oracle.com> Message-ID: On Sun, 23 May 2021 23:00:34 GMT, David Holmes wrote: > Right I just tracked that through before seeing this email. The fmul > uses the non-tmp version but later all lir_mul are assumed the same. compiler/c1/Test6855215.java passed on x86_32 with the latest version. More testing on x86_32 is in progress. Will let you know once finished. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From david.holmes at oracle.com Mon May 24 00:38:12 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 May 2021 10:38:12 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: References: <0e418bab-893f-f4b8-243b-b4e84a621cbb@oracle.com> Message-ID: <2567ba8c-c37c-89ce-54de-ef4844ca488b@oracle.com> On 24/05/2021 9:42 am, Jie Fu wrote: > On Sun, 23 May 2021 23:00:34 GMT, David Holmes wrote: > >> Right I just tracked that through before seeing this email. The fmul >> uses the non-tmp version but later all lir_mul are assumed the same. > > compiler/c1/Test6855215.java passed on x86_32 with the latest version. > > More testing on x86_32 is in progress. > Will let you know once finished. > Thanks. Thanks Jie - much appreciated! This won't be pushed till early next week, so plenty of time for additional testing. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From dholmes at openjdk.java.net Mon May 24 01:39:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 01:39:17 GMT Subject: RFR: 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() Message-ID: This is a trivial cleanup that was missed when "JDK-8252685 APIs that require JavaThread should take JavaThread arguments " was merged and integrated. Thanks to @calvinccheung for spotting this. Testing: tiers 1-3 (in progress) Thanks, David ------------- Commit messages: - 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() Changes: https://git.openjdk.java.net/jdk/pull/4160/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4160&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267553 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4160/head:pull/4160 PR: https://git.openjdk.java.net/jdk/pull/4160 From dholmes at openjdk.java.net Mon May 24 02:10:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 02:10:58 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:45:29 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: >> >>> 210: _thread->frame_anchor()->make_walkable(_thread); >>> 211: OrderAccess::storestore(); >>> 212: _thread->set_thread_state(_thread_in_native); >> >> Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? >> But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. > > Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. > But we have more of those. > > Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. > Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). > So yes it should always be there, good RFE! Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Mon May 24 02:33:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 02:33:03 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 02:08:43 GMT, David Holmes wrote: >> Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. >> But we have more of those. >> >> Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. >> Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). >> So yes it should always be there, good RFE! > > Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. > > Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. > > Thanks, > David I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion. The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From ccheung at openjdk.java.net Mon May 24 04:46:42 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 24 May 2021 04:46:42 GMT Subject: RFR: 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() In-Reply-To: References: Message-ID: On Mon, 24 May 2021 01:20:26 GMT, David Holmes wrote: > This is a trivial cleanup that was missed when "JDK-8252685 APIs that require JavaThread should take JavaThread arguments " was merged and integrated. > > Thanks to @calvinccheung for spotting this. > > Testing: tiers 1-3 (in progress) > > Thanks, > David Thanks for the quick fix. It looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4160 From iignatyev at openjdk.java.net Mon May 24 04:50:10 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 24 May 2021 04:50:10 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: <9alLklio3_96Au0yNPQhVq345vO1a2jPOyOVNqDuo5s=.d5126676-4eb5-4161-9e00-36737cce9105@github.com> On Fri, 21 May 2021 23:04:53 GMT, Jie Fu wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase MaxMetaspaceSize to 512k > > According to @dcubed-ojdk 's comments in the JBS, the latest change passed in Oracle's CI/CD. > Will push it tomorrow if there is no objection. > Thanks. @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From dholmes at openjdk.java.net Mon May 24 04:50:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 04:50:55 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Tue, 11 May 2021 11:59:23 GMT, Robbin Ehn wrote: > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > Fixed by leaving the handshakee being processed in queue until completed. > And remove looping, since if ever the queue is empty the handshakee may processed. > If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. > But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) > > Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. > > - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. > Fixed by adding a loadload. > > I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. > (real reprod ~1/400 with increased test time) > If we are updating the poll there should not be an active handshaker. > The above fixed the issue. > But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. > > Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). > > Passes stressing relevant test on aarch64 and t1-7. > > Thanks, Robbin Hi Robbin, I'm afraid these changes are very unclear to me. Other than not using is_locked() to determine if there is more work to do I really don't follow how the other changes relate to the failure mode. Thanks, David src/hotspot/share/runtime/handshake.cpp line 330: > 328: // closure are visible to the VMThread/Handshaker after it reads > 329: // that the operation has completed. > 330: Atomic::dec(&_pending_threads, memory_order_acq_rel); Should this just default to the full two-way barrier for atomic r-m-w operations? src/hotspot/share/runtime/handshake.cpp line 473: > 471: while (has_operation()) { > 472: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); > 473: HandshakeOperation* op = get_op_for_self(); I still don't understand why we now do a peek here, and then do the pop below (in remove-op), instead of just doing the pop here? src/hotspot/share/runtime/handshake.cpp line 570: > 568: Thread* current_thread = Thread::current(); > 569: > 570: HandshakeOperation* op = get_op(); Again why not pop here? src/hotspot/share/runtime/handshake.cpp line 592: > 590: executed++; > 591: } > 592: } while (have_non_self_executable_operation()); Not at all clear how/why this looping can now be removed. src/hotspot/share/runtime/handshake.cpp line 594: > 592: op == match_op ? "including" : "excluding", p2i(match_op)); > 593: > 594: return op == match_op ? HandshakeState::_succeeded : HandshakeState::_processed; Pre-existing: what does _processed mean versus _succeeded? src/hotspot/share/runtime/safepointMechanism.cpp line 116: > 114: > 115: void SafepointMechanism::update_poll_values(JavaThread* thread) { > 116: assert(thread == Thread::current(), "Must not be"); I assume the message should say "Must be". ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From dholmes at openjdk.java.net Mon May 24 05:33:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 05:33:43 GMT Subject: RFR: 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() In-Reply-To: References: Message-ID: On Mon, 24 May 2021 01:20:26 GMT, David Holmes wrote: > This is a trivial cleanup that was missed when "JDK-8252685 APIs that require JavaThread should take JavaThread arguments " was merged and integrated. > > Thanks to @calvinccheung for spotting this. > > Testing: tiers 1-3 (in progress) > > Thanks, > David Thanks Calvin! ------------- PR: https://git.openjdk.java.net/jdk/pull/4160 From dholmes at openjdk.java.net Mon May 24 05:33:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 05:33:44 GMT Subject: Integrated: 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() In-Reply-To: References: Message-ID: On Mon, 24 May 2021 01:20:26 GMT, David Holmes wrote: > This is a trivial cleanup that was missed when "JDK-8252685 APIs that require JavaThread should take JavaThread arguments " was merged and integrated. > > Thanks to @calvinccheung for spotting this. > > Testing: tiers 1-3 (in progress) > > Thanks, > David This pull request has now been integrated. Changeset: 31139108 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/31139108c1ca9d355bd484d692830dfbc8317477 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8267553: Extra JavaThread assignment in ClassLoader::create_class_path_entry() Reviewed-by: ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/4160 From jiefu at openjdk.java.net Mon May 24 06:18:14 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 06:18:14 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution In-Reply-To: <2567ba8c-c37c-89ce-54de-ef4844ca488b@oracle.com> References: <2567ba8c-c37c-89ce-54de-ef4844ca488b@oracle.com> Message-ID: On Mon, 24 May 2021 00:39:37 GMT, David Holmes wrote: > > Right I just tracked that through before seeing this email. The fmul > > uses the non-tmp version but later all lir_mul are assumed the same. > > compiler/c1/Test6855215.java passed on x86_32 with the latest version. > > More testing on x86_32 is in progress. > Will let you know once finished. All the tests passed on our Linux/x86_{64, 32}, no regression. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From github.com+16811675+linade at openjdk.java.net Mon May 24 06:18:56 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Mon, 24 May 2021 06:18:56 GMT Subject: RFR: 8266963: Reentrance condition for safepoint/handshake [v2] In-Reply-To: References: Message-ID: > Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. > > An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond > > I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. Yude Lin has updated the pull request incrementally with two additional commits since the last revision: - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. - Revert "8266963: Reentrance condition for safepoint/handshake" This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4028/files - new: https://git.openjdk.java.net/jdk/pull/4028/files/aa1ba235..9677d416 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4028&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4028&range=00-01 Stats: 43 lines in 4 files changed: 2 ins; 38 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4028.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4028/head:pull/4028 PR: https://git.openjdk.java.net/jdk/pull/4028 From jiefu at openjdk.java.net Mon May 24 06:24:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 06:24:11 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: <3_afbkSQUzvcf6ry1DzXLt12f_1BcnA7KjlkM4s1wEw=.7813429a-ca1f-4a07-be25-f9e09991069c@github.com> On Fri, 21 May 2021 23:04:53 GMT, Jie Fu wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase MaxMetaspaceSize to 512k > > According to @dcubed-ojdk 's comments in the JBS, the latest change passed in Oracle's CI/CD. > Will push it tomorrow if there is no objection. > Thanks. > @DamonFool , the goal of this test is to check that in case of (nearly) exhaused metaspace defining classes via `MethodHandles.Lookup::defineHiddenClass` will lead to OOME, after your rewriting, this test doesn't serve that purpose anymore, now it just checks that runnig `java -version` w/ small metaspace will lead to OOME. > > -- Igor Sorry, I didn't know that before since the background of the test is so limited (no bug ID, no design purpose comments, etc.). So what's your suggestion next? @iignatev Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From github.com+16811675+linade at openjdk.java.net Mon May 24 06:27:07 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Mon, 24 May 2021 06:27:07 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue In-Reply-To: <3jFXzMxaxGPL_Tbc-PbJJHG6wH0FLqm_Po4_DNw0p0c=.19a7a073-9db9-4635-b310-05c331dd280a@github.com> References: <3jFXzMxaxGPL_Tbc-PbJJHG6wH0FLqm_Po4_DNw0p0c=.19a7a073-9db9-4635-b310-05c331dd280a@github.com> Message-ID: On Tue, 18 May 2021 09:26:11 GMT, Yude Lin wrote: >> We can just remove this: >> >> if (i != 0 && thread->is_Java_thread()) { >> JavaThread* jt = thread->as_Java_thread(); >> if (jt->thread_state() == _thread_in_vm) { >> // Since this JavaThread has looped at least once and is _thread_in_vm, >> // we honor any pending blocking request. >> ThreadBlockInVM tbivm(jt); >> } >> } >> >> >> >> Under some wired circumstances it can prolong TTS. >> But it was me that found it. Reverting it wouldn't get any complains from anyone else. >> >> (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) > >> We can just remove this: >> >> if (i != 0 && thread->is_Java_thread()) { >> JavaThread* jt = thread->as_Java_thread(); >> if (jt->thread_state() == _thread_in_vm) { >> // Since this JavaThread has looped at least once and is _thread_in_vm, >> // we honor any pending blocking request. >> ThreadBlockInVM tbivm(jt); >> } >> } >> >> Under some wired circumstances it can prolong TTS. >> But it was me that found it. Reverting it wouldn't get any complains from anyone else. >> >> (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also) > > In that case this is a solution I can get behind. > >> The issue is that inside the handshake closure you would transition to >> the blocked state in ThreadBlockInVM(), which allows a safepoint to >> proceed. If in ~ThreadBlockInVM() we don't stop for the safepoint and >> just return in SafepointMechanism::process_if_requested_slow() then now >> you would have a safepoint and handshake executing at the same time. > > Ah I see, there I was thinking a thread is only considered in safepoint by VM Thread when it's blocked in SafepointMechanism::process, but it actually happen when transitioned to the _thread_blocked state. Thanks for pointing it out! > @linade will you re-do the PR with that change instead? Done. Sorry for the delay. Would you take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From iignatyev at openjdk.java.net Mon May 24 06:43:43 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 24 May 2021 06:43:43 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: <3fPjUjeMXNzT7eOj1z51dIP1ekW2gz3uiPv3HhdpJzU=.ad9ed47d-2ea4-4861-9664-ccc00bfe4b52@github.com> On Fri, 21 May 2021 15:19:17 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Increase MaxMetaspaceSize to 512k well, although I agree that the test might have done a better job explaining its purpose, it did have a javadoc: `This test loads classes using defineHiddenClass and stores them, expecting Metaspace OOME` and its location (`vm/mlvm/anonloader/stress/oome/metaspace`) suggests that it's a test for anonymous classloader (it used to use `Unsafe::defineAnonymousClass` till it get removed) part of mlvm (jsr292), and it's supposed to stress metaspace in near OOME state, so it's unfair to say it didn't state its purpose at all. I haven't followed this RFR thread closely, so I can't suggest you the way to fix the test, but I strongly advise you to restore its logic, that's to say backout `6288a9936cc7e69cab0cc5f3e49c803f184bf2ca` and work on the proper fix which will preserve the original intent of the test. -- Igor after spending some time looking at the original test, I'm wondering if we need `-Xmx`, `-XX:MaxMetaspaceSize`, `-XX:MetaspaceSize` at all. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From rehn at openjdk.java.net Mon May 24 06:46:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 06:46:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: <0JV9oMEZMPk-NIIsIQXvsQwCz1gbs40NtHLARinkI68=.4c4ad9b7-6cca-4e39-83c4-869bbe2853aa@github.com> On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Final fixes: last famous words Are we good to go? Thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 24 06:46:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 06:46:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 02:29:23 GMT, David Holmes wrote: >> Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. >> >> Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. >> >> Thanks, >> David > > I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion. > > The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE. > > Thanks, > David Sounds good, thank. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 24 06:48:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 06:48:43 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. Thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4028 From jiefu at openjdk.java.net Mon May 24 07:21:57 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 07:21:57 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <3fPjUjeMXNzT7eOj1z51dIP1ekW2gz3uiPv3HhdpJzU=.ad9ed47d-2ea4-4861-9664-ccc00bfe4b52@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> <3fPjUjeMXNzT7eOj1z51dIP1ekW2gz3uiPv3HhdpJzU=.ad9ed47d-2ea4-4861-9664-ccc00bfe4b52@github.com> Message-ID: On Mon, 24 May 2021 06:41:38 GMT, Igor Ignatyev wrote: > after spending some time looking at the original test, I'm wondering if we need `-Xmx`, `-XX:MaxMetaspaceSize`, `-XX:MetaspaceSize` at all. Let's wait for @tstuefe 's opinion about this suggestion. But please feel free to do what you want if you think it is urgent. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From iignatyev at openjdk.java.net Mon May 24 07:48:45 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 24 May 2021 07:48:45 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Fri, 21 May 2021 15:19:17 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Increase MaxMetaspaceSize to 512k There is no urgency in restoring the test(given it was problem listed), so I?m fine w/ waiting for Thomas? opinion. meanwhile, I?ve verified that if we remove `Xmx`, the test passes on Oracle build of linux-aarch64 in the configuration it used to fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Mon May 24 08:05:06 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 08:05:06 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Mon, 24 May 2021 07:44:57 GMT, Igor Ignatyev wrote: > There is no urgency in restoring the test(given it was problem listed), so I?m fine w/ waiting for Thomas? opinion. Thanks for your understanding. > meanwhile, I?ve verified that if we remove `Xmx`, the test passes on Oracle build of linux-aarch64 in the configuration it used to fail. For Oracle build of linux-aarch64, it wouldn't fail without `-Xmx` before. The failure was sighting due to extra `-Xmx` was added in the test, which tried to fix JDK-8267293 . More background is here: https://github.com/openjdk/jdk/pull/4062#issuecomment-842495119 Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From iignatyev at openjdk.java.net Mon May 24 08:21:10 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 24 May 2021 08:21:10 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Mon, 24 May 2021 08:01:47 GMT, Jie Fu wrote: > For Oracle build of linux-aarch64, it wouldn't fail without -Xmx before. I see, and in what cases did it fail w/o `-Xmx`? this test isn't supposed to be run concurrently w/ any other tests (and hopefully when [CODETOOLS-7902831](https://bugs.openjdk.java.net/browse/CODETOOLS-7902831) / openjdk/jtreg#4 gets fixed it will be indeed), so I *guess* we might as well explicitly set `-XX:MaxRAMPercentage=25.0` in the test (instead of `-Xmx`). Cheers, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From vlivanov at openjdk.java.net Mon May 24 08:24:14 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 24 May 2021 08:24:14 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v5] In-Reply-To: References: Message-ID: <5JNAmB403uJNxNaTvG3N2ZAoBWRgGFGL08ynYKJ3F9Y=.d7d1e78a-6450-4283-a64a-2faee9ff4255@github.com> On Sun, 23 May 2021 23:14:08 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into jep-306 > - The code for strict handling only applies to doubles. > - Add missing space > - lir_div_strictfp and lir_mul_strictfp > - Removed divDPR_reg_round as it has a false predicate and so is now unused > - Revert classFileParser changes as they will be handled by JDK-8266530 > - 8266530: HotSpot changes for JEP 306 > All methods are now implicitly strictfp so all code generation etc > uses the strict form. > There are still some names that include "strict" that could potentially > be renamed to rmeove it, but the fact we have to have strict fp semantics > is still important on some platforms, so the names help reinforce that IMO. Marked as reviewed by vlivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From duke at openjdk.java.net Mon May 24 08:26:05 2021 From: duke at openjdk.java.net (duke) Date: Mon, 24 May 2021 08:26:05 GMT Subject: Withdrawn: 8263603: Remove leftovers of "FPE_FLT..." type signals from regular signal handling code In-Reply-To: References: Message-ID: <16IJ__4CdftdJb__ZptPX1ui5xwBtqYYGYz1Wk0yWs0=.ca3a01fc-e365-4eb1-8558-defdca510606@github.com> On Wed, 24 Mar 2021 15:36:06 GMT, Gerard Ziemski wrote: > hello everyone, > > Signal handling code is complex as it is, this enhancement removes, incorrect, catching & handling of `FPE_FLT` types of signals. > > It's incorrect, because: > > - We wouldn't want to generate/catch a floating point div by zero instructions, which by default do not cause a crash (only integer div by 0 cause crash) > > - We can't catch them because that would require us to set **FPU** to raise such signals, which we don't do > > - Even if we wanted to generate **FPU** signals, those only originate in **x87 FPU**, which we are not using (we use **SSE** instructions for floating point arithmetic instead) on **x86_64** architecture. Finally the API to turn it on is not even available on macOS at all (it's seems to be available on Linux, but I don't know what it actually does on **64 bit** architecture, if anything) > > If we were to catch `FPE_FLT` signal it most likely is a bug in the OS itself, like for example [JDK-8261397](https://bugs.openjdk.java.net/browse/JDK-8261397) > > In anticipation of such scenarios we have a generic handling of `FPE_FLT`, but we report it as OS bug that needs to be investigated. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3175 From jiefu at openjdk.java.net Mon May 24 08:47:05 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 08:47:05 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Fri, 21 May 2021 15:19:17 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Increase MaxMetaspaceSize to 512k > so I _guess_ we might as well explicitly set `-XX:MaxRAMPercentage=25.0` in the test (instead of `-Xmx`). This seems reasonable to me. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From iignatyev at openjdk.java.net Mon May 24 09:06:19 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 24 May 2021 09:06:19 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Fri, 21 May 2021 15:19:17 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java OOMEs on Oracle's aarch64 platforms. >> The reason is that both -Xmx and -XX:MetaspaceSize are not enough. >> >> From the original JBS decription of JDK-8267404, the VM OOMEs before the expected OOME in metaspace happened showing that -Xmx256m is not enough. >> >> Then, @dcubed-ojdk helped me test with -Xmx512, which still OOMEs. >> However, the expected OOME in metaspace was caught this time. >> But a second uncaught OOME in metaspace happened soon, which means -XX:MetaspaceSize=8m is not enough. >> >> So both -Xmx and -XX:MetaspaceSize should be increased. >> The fix just: >> - Revert changes about mataspace size setting >> - Increase -Xmx from 256m to 1g >> >> -Xmx512m may be OK on Oracle's aarch64 machines, but to make it safer, -Xmx1g is preferred. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Increase MaxMetaspaceSize to 512k this will, however, only solve the problem w/ the test; but I also share Thomas' [concern](https://github.com/openjdk/jdk/pull/4140#issuecomment-845836298)[*], we shouldn't need 1g (or even .5g) of heap space to eat up 20m of metaspace (even w/ small classes like `AnonkTestee01`), so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately. -- Igor [*] > What I am concerned about is that with there should not be that much variance in how much heap space we use. Sure you can set it to 1g or 2g, but something is clearly off. I get by on Linux x64 with 128m, on 32bit x86 with 256m (since we don't have CompressedClassPointers we need somewhat more heap). But needing 1g on aarch64 seems weird. ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From jiefu at openjdk.java.net Mon May 24 09:12:10 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 24 May 2021 09:12:10 GMT Subject: RFR: 8267404: vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java failed with OutOfMemoryError [v3] In-Reply-To: References: <8eRvpcobttghvvkuixH_Z2pPXwI4ACHcz61psYCV-W4=.8be9e047-4e3c-43e2-8082-24f9a9a755e3@github.com> Message-ID: On Mon, 24 May 2021 09:03:01 GMT, Igor Ignatyev wrote: > so there seems to be an underlying defect in `linux-aarch64` build, which will need to be investigated/addressed separately. Yes, I think that makes sense since all of our linux-aarch64 platforms couldn't reproduce the OOME except those of Oracle's . ------------- PR: https://git.openjdk.java.net/jdk/pull/4140 From dholmes at openjdk.java.net Mon May 24 09:30:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 09:30:06 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. Hold on a moment! This undoes 8262443, so what happens with the issue that bug was fixing? David ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From rehn at openjdk.java.net Mon May 24 09:54:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 09:54:19 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 09:27:15 GMT, David Holmes wrote: > Hold on a moment! This undoes 8262443, so what happens with the issue that bug was fixing? As I said above, it's seem like I'm the only one seen an issue with this, so I'm the finder/reporter and fixer of the original bug. In a ZGC branch they run this code in StackWater, which than also hits this problem. Since this is just a performance enhancement it was suggested to just remove this. I don't have time to figure out exactly what happens when we start looping here, so I'm fine with removing this for now. Thanks, Robbin > > David ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From rehn at openjdk.java.net Mon May 24 10:09:01 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:09:01 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Tue, 18 May 2021 07:21:32 GMT, David Holmes wrote: >> Please consider this change-set which address the issue on hand. >> >> I identified two problems: >> >> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >> Fixed by leaving the handshakee being processed in queue until completed. >> And remove looping, since if ever the queue is empty the handshakee may processed. >> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. >> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) >> >> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. >> >> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. >> Fixed by adding a loadload. >> >> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. >> (real reprod ~1/400 with increased test time) >> If we are updating the poll there should not be an active handshaker. >> The above fixed the issue. >> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. >> >> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). >> >> Passes stressing relevant test on aarch64 and t1-7. >> >> Thanks, Robbin > > src/hotspot/share/runtime/handshake.cpp line 330: > >> 328: // closure are visible to the VMThread/Handshaker after it reads >> 329: // that the operation has completed. >> 330: Atomic::dec(&_pending_threads, memory_order_acq_rel); > > Should this just default to the full two-way barrier for atomic r-m-w operations? Sure, why not, changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 24 10:25:01 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:25:01 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Mon, 24 May 2021 04:33:18 GMT, David Holmes wrote: >> Please consider this change-set which address the issue on hand. >> >> I identified two problems: >> >> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >> Fixed by leaving the handshakee being processed in queue until completed. >> And remove looping, since if ever the queue is empty the handshakee may processed. >> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. >> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) >> >> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. >> >> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. >> Fixed by adding a loadload. >> >> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. >> (real reprod ~1/400 with increased test time) >> If we are updating the poll there should not be an active handshaker. >> The above fixed the issue. >> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. >> >> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). >> >> Passes stressing relevant test on aarch64 and t1-7. >> >> Thanks, Robbin > > src/hotspot/share/runtime/handshake.cpp line 473: > >> 471: while (has_operation()) { >> 472: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >> 473: HandshakeOperation* op = get_op_for_self(); > > I still don't understand why we now do a peek here, and then do the pop below (in remove-op), instead of just doing the pop here? The reason is, from above: >When poll is armed the handshakee must go to slow path and lock the HandshakeState lock if: >- 1: There is handshake operation to be processed >- 2: Some-else is in the middle of processing a handshake operation for this handshakee This, in practice, means the first pointer of the queue most be non-NULL, and seen as non-NULL, until after we have processed the handshake operation. By doing: 1: get op 2: do op - When handshakee first checks poll, it is armed. - Then it checks global poll (safepoint) and the queue state. - If there is a handshake operation to be processed goto slow path. 3: remove op - First ptr can be set NULL, which means the handshakee may elide the slow path. - The handshakee sees poll armed, but no global poll and nothing in queue. - The handshakee may disarm the poll. By simply removing the OP after we have executed we know the handshakee must go to slow path. > src/hotspot/share/runtime/handshake.cpp line 570: > >> 568: Thread* current_thread = Thread::current(); >> 569: >> 570: HandshakeOperation* op = get_op(); > > Again why not pop here? See above. If there was only one OP in queue, the handshake may now disarm it's poll and continue. If there is more in queue it will still go to slow path. ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 24 10:25:02 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:25:02 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Mon, 24 May 2021 10:15:04 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 473: >> >>> 471: while (has_operation()) { >>> 472: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >>> 473: HandshakeOperation* op = get_op_for_self(); >> >> I still don't understand why we now do a peek here, and then do the pop below (in remove-op), instead of just doing the pop here? > > The reason is, from above: >>When poll is armed the handshakee must go to slow path and lock the HandshakeState lock if: >>- 1: There is handshake operation to be processed >>- 2: Some-else is in the middle of processing a handshake operation for this handshakee > > This, in practice, means the first pointer of the queue most be non-NULL, and seen as non-NULL, until after we have processed the handshake operation. > By doing: > 1: get op > 2: do op > - When handshakee first checks poll, it is armed. > - Then it checks global poll (safepoint) and the queue state. > - If there is a handshake operation to be processed goto slow path. > 3: remove op > - First ptr can be set NULL, which means the handshakee may elide the slow path. > - The handshakee sees poll armed, but no global poll and nothing in queue. > - The handshakee may disarm the poll. > > By simply removing the OP after we have executed we know the handshakee must go to slow path. Oh, sorry you mean when you are self processing? It's because of symmetry, everyone do the same, which is far easier to think about. >> src/hotspot/share/runtime/handshake.cpp line 570: >> >>> 568: Thread* current_thread = Thread::current(); >>> 569: >>> 570: HandshakeOperation* op = get_op(); >> >> Again why not pop here? > > See above. > > If there was only one OP in queue, the handshake may now disarm it's poll and continue. > If there is more in queue it will still go to slow path. So comment above applies here, we must not let queue become empty until OP is completed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 24 10:31:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:31:19 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: <6pt1avomodq-BjwJksgo6tjCSGnjX1rS1JiNNKocEo0=.bfab01b2-2c2f-4b82-958d-3271c00c5505@github.com> On Mon, 24 May 2021 04:41:22 GMT, David Holmes wrote: >> Please consider this change-set which address the issue on hand. >> >> I identified two problems: >> >> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >> Fixed by leaving the handshakee being processed in queue until completed. >> And remove looping, since if ever the queue is empty the handshakee may processed. >> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. >> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) >> >> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. >> >> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. >> Fixed by adding a loadload. >> >> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. >> (real reprod ~1/400 with increased test time) >> If we are updating the poll there should not be an active handshaker. >> The above fixed the issue. >> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. >> >> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). >> >> Passes stressing relevant test on aarch64 and t1-7. >> >> Thanks, Robbin > > src/hotspot/share/runtime/handshake.cpp line 592: > >> 590: executed++; >> 591: } >> 592: } while (have_non_self_executable_operation()); > > Not at all clear how/why this looping can now be removed. It must be removed. Since we have concurrent adds. Thread P: get OP X Thread P: do OP X Thread P: remove OP X Handshakee: is queue empty? Yes, can continue to e.g. Java Thread X: add OP Z Thread P: Is there more OP's to be execute ? Yes => Error, handshakee did not see that OP. So Thread P needs to verify that the handshakee did see that operation. To do that we need to make sure poll is armed and that the handshakee is in handshake safe state. Which means we need to redo everything; by just returning from this method we do this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 24 10:35:07 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:35:07 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: On Mon, 24 May 2021 04:42:00 GMT, David Holmes wrote: >> Please consider this change-set which address the issue on hand. >> >> I identified two problems: >> >> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >> Fixed by leaving the handshakee being processed in queue until completed. >> And remove looping, since if ever the queue is empty the handshakee may processed. >> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. >> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) >> >> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. >> >> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. >> Fixed by adding a loadload. >> >> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. >> (real reprod ~1/400 with increased test time) >> If we are updating the poll there should not be an active handshaker. >> The above fixed the issue. >> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. >> >> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). >> >> Passes stressing relevant test on aarch64 and t1-7. >> >> Thanks, Robbin > > src/hotspot/share/runtime/handshake.cpp line 594: > >> 592: op == match_op ? "including" : "excluding", p2i(match_op)); >> 593: >> 594: return op == match_op ? HandshakeState::_succeeded : HandshakeState::_processed; > > Pre-existing: what does _processed mean versus _succeeded? - Processed means we did progress, so do not yield. - Succeeded means you processed the OP you add to the queue. (For your purposes you don't need to revisit this handshakee) > src/hotspot/share/runtime/safepointMechanism.cpp line 116: > >> 114: >> 115: void SafepointMechanism::update_poll_values(JavaThread* thread) { >> 116: assert(thread == Thread::current(), "Must not be"); > > I assume the message should say "Must be". Yes, fixing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From rehn at openjdk.java.net Mon May 24 10:42:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 10:42:55 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be [v2] In-Reply-To: References: Message-ID: > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > Fixed by leaving the handshakee being processed in queue until completed. > And remove looping, since if ever the queue is empty the handshakee may processed. > If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. > But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) > > Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. > > - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. > Fixed by adding a loadload. > > I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. > (real reprod ~1/400 with increased test time) > If we are updating the poll there should not be an active handshaker. > The above fixed the issue. > But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. > > Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). > > Passes stressing relevant test on aarch64 and t1-7. > > Thanks, Robbin Robbin Ehn 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: - Small update - Merge branch 'master' into handshakee - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3973/files - new: https://git.openjdk.java.net/jdk/pull/3973/files/b8750e44..03bbb423 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=00-01 Stats: 33940 lines in 1057 files changed: 15001 ins; 12695 del; 6244 mod Patch: https://git.openjdk.java.net/jdk/pull/3973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973 PR: https://git.openjdk.java.net/jdk/pull/3973 From zgu at openjdk.java.net Mon May 24 12:09:08 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 24 May 2021 12:09:08 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. Look good, Thanks. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4028 From david.holmes at oracle.com Mon May 24 12:37:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 May 2021 22:37:29 +1000 Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: <3509b7e2-542e-0b93-b9d3-633f78e5cbd7@oracle.com> On 24/05/2021 7:54 pm, Robbin Ehn wrote: > On Mon, 24 May 2021 09:27:15 GMT, David Holmes wrote: > >> Hold on a moment! This undoes 8262443, so what happens with the issue that bug was fixing? > > As I said above, it's seem like I'm the only one seen an issue with this, so I'm the finder/reporter and fixer of the original bug. > In a ZGC branch they run this code in StackWater, which than also hits this problem. > Since this is just a performance enhancement it was suggested to just remove this. > > I don't have time to figure out exactly what happens when we start looping here, so I'm fine with removing this for now. In that case 8262443 needs to be updated to explain this. Thanks, David > Thanks, Robbin > >> >> David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4028 > From david.holmes at oracle.com Mon May 24 12:44:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 May 2021 22:44:02 +1000 Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: References: Message-ID: <56466454-3c3f-cc7c-039f-1c344c3c2164@oracle.com> On 24/05/2021 8:25 pm, Robbin Ehn wrote: > On Mon, 24 May 2021 04:33:18 GMT, David Holmes wrote: > >>> Please consider this change-set which address the issue on hand. >>> >>> I identified two problems: >>> >>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. >>> Fixed by leaving the handshakee being processed in queue until completed. >>> And remove looping, since if ever the queue is empty the handshakee may processed. >>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. >>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) >>> >>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. >>> >>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. >>> Fixed by adding a loadload. >>> >>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. >>> (real reprod ~1/400 with increased test time) >>> If we are updating the poll there should not be an active handshaker. >>> The above fixed the issue. >>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. >>> >>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). >>> >>> Passes stressing relevant test on aarch64 and t1-7. >>> >>> Thanks, Robbin >> >> src/hotspot/share/runtime/handshake.cpp line 473: >> >>> 471: while (has_operation()) { >>> 472: MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >>> 473: HandshakeOperation* op = get_op_for_self(); >> >> I still don't understand why we now do a peek here, and then do the pop below (in remove-op), instead of just doing the pop here? > > The reason is, from above: >> When poll is armed the handshakee must go to slow path and lock the HandshakeState lock if: >> - 1: There is handshake operation to be processed >> - 2: Some-else is in the middle of processing a handshake operation for this handshakee > > This, in practice, means the first pointer of the queue most be non-NULL, and seen as non-NULL, until after we have processed the handshake operation. > By doing: > 1: get op > 2: do op > - When handshakee first checks poll, it is armed. > - Then it checks global poll (safepoint) and the queue state. > - If there is a handshake operation to be processed goto slow path. > 3: remove op > - First ptr can be set NULL, which means the handshakee may elide the slow path. > - The handshakee sees poll armed, but no global poll and nothing in queue. > - The handshakee may disarm the poll. > > By simply removing the OP after we have executed we know the handshakee must go to slow path. What are you calling the "slow path" here? I think I need a refresher course on the basics of the handshake mechanism as I am not understanding this at all sorry. David ----- >> src/hotspot/share/runtime/handshake.cpp line 570: >> >>> 568: Thread* current_thread = Thread::current(); >>> 569: >>> 570: HandshakeOperation* op = get_op(); >> >> Again why not pop here? > > See above. > > If there was only one OP in queue, the handshake may now disarm it's poll and continue. > If there is more in queue it will still go to slow path. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3973 > From rehn at openjdk.java.net Mon May 24 12:52:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 12:52:06 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be In-Reply-To: <56466454-3c3f-cc7c-039f-1c344c3c2164@oracle.com> References: <56466454-3c3f-cc7c-039f-1c344c3c2164@oracle.com> Message-ID: On Mon, 24 May 2021 12:45:37 GMT, David Holmes wrote: > What are you calling the "slow path" here? "need_rechecking = thread->handshake_state()->has_operation() && thread->handshake_state()->process_by_self();" If has_operation() returns false we continue out of the transition into an unsafe state. Thus has_operation() must return true until it is safe to do so. It's same as for global_poll(), which must return true util the safepoint is over. Thanks, Robbin > > I think I need a refresher course on the basics of the handshake > mechanism as I am not understanding this at all sorry. > > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/3973 From ayang at openjdk.java.net Mon May 24 15:34:50 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 24 May 2021 15:34:50 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends Message-ID: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. ------------- Commit messages: - as_worker_thread Changes: https://git.openjdk.java.net/jdk/pull/4167/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4167&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252476 Stats: 11 lines in 2 files changed: 5 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4167.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4167/head:pull/4167 PR: https://git.openjdk.java.net/jdk/pull/4167 From dcubed at openjdk.java.net Mon May 24 16:15:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 24 May 2021 16:15:24 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic Message-ID: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). Also refactor common hash table size calculation code into static hash_table_size() function and call it from both places. Test with Mach5 Tier[1-7] testing. ------------- Commit messages: - 8191786: Thread-SMR hash table size should be dynamic Changes: https://git.openjdk.java.net/jdk/pull/4168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8191786 Stats: 55 lines in 1 file changed: 17 ins; 15 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4168/head:pull/4168 PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Mon May 24 18:25:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 24 May 2021 18:25:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Final fixes: last famous words Thumbs up. I just have some minor questions about a couple of the details. Nothing blocking. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405: > 403: > 404: guarantee(self == _owner, "invariant"); > 405: guarantee(save == _recursions, "invariant"); Since you just restored the `_recursions` field on L402, why do you need this guarantee() 2 code lines later? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > 210: _thread->frame_anchor()->make_walkable(_thread); > 211: OrderAccess::storestore(); > 212: _thread->set_thread_state(_thread_in_native); Please add a comment to the `storestore()` call: // Keep thread_state change and make_walkable() separate. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251: > 249: thread->frame_anchor()->make_walkable(thread); > 250: OrderAccess::storestore(); > 251: thread->set_thread_state(_thread_blocked); Please add a comment to the storestore() call: // Keep thread_state change and make_walkable() separate. src/hotspot/share/runtime/objectMonitor.cpp line 435: > 433: ThreadBlockInVMPreprocess tbivs(current, eos); > 434: EnterI(current); > 435: current->set_current_pending_monitor(NULL); `current->set_current_pending_monitor(this)` is called above on L413 which is before the `for(;;)` loop so after this call to clear the pending monitor, if we loop again, we will no longer have a pending monitor set. That's a change in behavior from when the pending monitor was set to NULL on old L435 below. I'm not sure why you move the code from old L435 (outside the loop) to new L435 (inside the loop). Update: I found this resolved comment below: > And I set current->set_current_pending_monitor(om); to OM again > in ExitOnSuspend if we exit the OM. so that explains why we don't have a big change in behavior. src/hotspot/share/runtime/objectMonitor.cpp line 451: > 449: // We cleared the pending monitor info since we've just gotten past > 450: // the enter-check-for-suspend dance and we now own the monitor free > 451: // and clear, i.e., it is no longer pending. This comment explains why the set-pending-to-NULL code was here (outside the loop). You moved the code, but now the comment is misplaced and the code no longer works the same. Update: I found this resolved comment below: And I set current->set_current_pending_monitor(om); to OM again in ExitOnSuspend if we exit the OM. so that explains why we don't have a big change in behavior. However, I think you still need to do something about this comment. There is still an observable change in behavior in that the current pending monitor can cycle between set->NULL->set->NULL when we run into a suspend request. Previously, it did not cycle. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From ccheung at openjdk.java.net Mon May 24 21:53:33 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 24 May 2021 21:53:33 GMT Subject: RFR: 8261478: InstanceKlass::set_classpath_index does not match comments Message-ID: A simple patch for updating the comment for the `InstanceKlass::set_classpath_index()` function. ------------- Commit messages: - 8261478: InstanceKlass::set_classpath_index does not match comments Changes: https://git.openjdk.java.net/jdk/pull/4170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261478 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4170/head:pull/4170 PR: https://git.openjdk.java.net/jdk/pull/4170 From iklam at openjdk.java.net Mon May 24 21:57:12 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 24 May 2021 21:57:12 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class [v2] In-Reply-To: References: Message-ID: <3Ker5wfEzKTK3b5ialwwUOgX_2kTuiPW14xhZB1iwmI=.1bd08d08-3cc4-435e-be86-882857f2ec87@github.com> > In CDS terms, "Unregistered classes" are the archived classes that should be loaded by custom class loaders during runtime. Archiving of class loader constraints ([JDK-8178349](https://bugs.openjdk.java.net/browse/JDK-8178349)) should be disabled for such classes. > > During CDS dump time (-Xshare:dump), unregistered classes are loaded by the boot loader (see also [JDK-8261941](https://bugs.openjdk.java.net/browse/JDK-8261941)). `SystemDictionaryShared::record_linking_constraint` doesn't properly recognize such classes, leading to the assert. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8267347-record_linking_constraint-asserts - PR comments by @yminqi and @calvinccheung - fixed windows testing - 8267347: CDS record_linking_constraint asserts with unregistered class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4147/files - new: https://git.openjdk.java.net/jdk/pull/4147/files/ee9a22f4..cd9b60d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4147&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4147&range=00-01 Stats: 5758 lines in 970 files changed: 2683 ins; 1797 del; 1278 mod Patch: https://git.openjdk.java.net/jdk/pull/4147.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4147/head:pull/4147 PR: https://git.openjdk.java.net/jdk/pull/4147 From iklam at openjdk.java.net Mon May 24 21:57:53 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 24 May 2021 21:57:53 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 21:40:32 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8267347-record_linking_constraint-asserts >> - PR comments by @yminqi and @calvinccheung >> - fixed windows testing >> - 8267347: CDS record_linking_constraint asserts with unregistered class > > Looks good. Just one question and one nit. Thanks to @calvinccheung and @yminqi for the review. > test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 52: > >> 50: httpHandlerClass, >> 51: httpExchangeClass, >> 52: Asserts.class.getName(), > > Why other class names don't need to do `replace(".", "/")`? The problem is that the classlist requires the slash separator. I.e., `com/sun/net/httpserver/HttpHandler` must be used. In contrast, `ClassFileInstaller.writeJar()` allows both `jdk.test.lib.Asserts` and `jdk/test/lib/Asserts`. Since the `Asserts` class is used only by `ClassFileInstaller`, I left it as is. To make it easier to write test cases, I have filed https://bugs.openjdk.java.net/browse/JDK-8267624 "CDS classlist should allow both . and / in class names" > test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java line 32: > >> 30: >> 31: // This is a handy class for running an application inside a custom class loader. This >> 32: // is used for testing CDS handling of unregistered classes (i.e., archved classes loaded > > Typo: archved -> archived Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4147 From iklam at openjdk.java.net Mon May 24 21:58:37 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 24 May 2021 21:58:37 GMT Subject: RFR: 8267347: CDS record_linking_constraint asserts with unregistered class [v2] In-Reply-To: References: Message-ID: <_r8nYmQ6an2jSpcfsXxve7zJc-SEjPSeWEI5Fzj660E=.bcab7b5c-2744-45f1-bd5f-d2fe44868f44@github.com> On Fri, 21 May 2021 19:04:41 GMT, Yumin Qi wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8267347-record_linking_constraint-asserts >> - PR comments by @yminqi and @calvinccheung >> - fixed windows testing >> - 8267347: CDS record_linking_constraint asserts with unregistered class > > test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java line 104: > >> 102: String testCase = Integer.toString(i); >> 103: String cmdLine[] = new String[] { >> 104: "--add-modules", > > Here is not aligned with below. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4147 From iklam at openjdk.java.net Mon May 24 22:33:35 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 24 May 2021 22:33:35 GMT Subject: Integrated: 8267347: CDS record_linking_constraint asserts with unregistered class In-Reply-To: References: Message-ID: On Fri, 21 May 2021 17:58:25 GMT, Ioi Lam wrote: > In CDS terms, "Unregistered classes" are the archived classes that should be loaded by custom class loaders during runtime. Archiving of class loader constraints ([JDK-8178349](https://bugs.openjdk.java.net/browse/JDK-8178349)) should be disabled for such classes. > > During CDS dump time (-Xshare:dump), unregistered classes are loaded by the boot loader (see also [JDK-8261941](https://bugs.openjdk.java.net/browse/JDK-8261941)). `SystemDictionaryShared::record_linking_constraint` doesn't properly recognize such classes, leading to the assert. This pull request has now been integrated. Changeset: 209769b5 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/209769b5ad462ce3dd47f18d93e12147730f8123 Stats: 160 lines in 5 files changed: 138 ins; 4 del; 18 mod 8267347: CDS record_linking_constraint asserts with unregistered class Reviewed-by: minqi, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/4147 From minqi at openjdk.java.net Mon May 24 23:03:11 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 24 May 2021 23:03:11 GMT Subject: RFR: 8261478: InstanceKlass::set_classpath_index does not match comments In-Reply-To: References: Message-ID: On Mon, 24 May 2021 18:42:25 GMT, Calvin Cheung wrote: > A simple patch for updating the comment for the `InstanceKlass::set_classpath_index()` function. LGTM. This is a leftover of JDK-8240204. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4170 From ccheung at openjdk.java.net Tue May 25 00:34:28 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 25 May 2021 00:34:28 GMT Subject: RFR: 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime Message-ID: A simple patch for renaming the `InstanceKlass::has_old_class_version` function to `InstanceKlass::can_be_verified_at_dumptime`. - [x] passed tier1, tier2 tests ------------- Commit messages: - 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime Changes: https://git.openjdk.java.net/jdk/pull/4176/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4176&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267431 Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4176.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4176/head:pull/4176 PR: https://git.openjdk.java.net/jdk/pull/4176 From iklam at openjdk.java.net Tue May 25 00:39:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 25 May 2021 00:39:59 GMT Subject: RFR: 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime In-Reply-To: References: Message-ID: On Tue, 25 May 2021 00:25:33 GMT, Calvin Cheung wrote: > A simple patch for renaming the `InstanceKlass::has_old_class_version` function to `InstanceKlass::can_be_verified_at_dumptime`. > > - [x] passed tier1, tier2 tests Looks good and trivial. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4176 From ccheung at openjdk.java.net Tue May 25 00:46:07 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 25 May 2021 00:46:07 GMT Subject: RFR: 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime In-Reply-To: References: Message-ID: <4s-2vKbnu-Ld1J6O77kbbjJRvIEQ4dznBzLD1Ccs47M=.7eda252c-61e6-45b0-b5b6-ebab18d2a338@github.com> On Tue, 25 May 2021 00:37:05 GMT, Ioi Lam wrote: >> A simple patch for renaming the `InstanceKlass::has_old_class_version` function to `InstanceKlass::can_be_verified_at_dumptime`. >> >> - [x] passed tier1, tier2 tests > > Looks good and trivial. Thanks @iklam. ------------- PR: https://git.openjdk.java.net/jdk/pull/4176 From ccheung at openjdk.java.net Tue May 25 00:46:08 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 25 May 2021 00:46:08 GMT Subject: Integrated: 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime In-Reply-To: References: Message-ID: On Tue, 25 May 2021 00:25:33 GMT, Calvin Cheung wrote: > A simple patch for renaming the `InstanceKlass::has_old_class_version` function to `InstanceKlass::can_be_verified_at_dumptime`. > > - [x] passed tier1, tier2 tests This pull request has now been integrated. Changeset: de27da7d Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/de27da7dedb217481b5e1582c38313232828a18c Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod 8267431: Rename InstanceKlass::has_old_class_version to can_be_verified_at_dumptime Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/4176 From dholmes at openjdk.java.net Tue May 25 00:48:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 00:48:24 GMT Subject: RFR: 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core Message-ID: Please review this trivial test fix to add -XX:-CreateCoredumpOnCrash to the exec'd VM that we expect to crash with SIGILL. If the core dump is generated it can take a long time on macos and cause the whole test to timeout. Testing: ran 50x on macos-x64, plus local linux-x64 Thanks, David ------------- Commit messages: - 8267651: runtime/handshake/HandshakeTimeoutTest.java times out will dumping core Changes: https://git.openjdk.java.net/jdk/pull/4177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267651 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4177/head:pull/4177 PR: https://git.openjdk.java.net/jdk/pull/4177 From ccheung at openjdk.java.net Tue May 25 00:52:07 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 25 May 2021 00:52:07 GMT Subject: RFR: 8261478: InstanceKlass::set_classpath_index does not match comments In-Reply-To: References: Message-ID: On Mon, 24 May 2021 23:00:12 GMT, Yumin Qi wrote: >> A simple patch for updating the comment for the `InstanceKlass::set_classpath_index()` function. > > LGTM. This is a leftover of JDK-8240204. Thanks @yminqi. Since this is a comment only change, I'll integrate now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4170 From ccheung at openjdk.java.net Tue May 25 00:52:08 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 25 May 2021 00:52:08 GMT Subject: Integrated: 8261478: InstanceKlass::set_classpath_index does not match comments In-Reply-To: References: Message-ID: On Mon, 24 May 2021 18:42:25 GMT, Calvin Cheung wrote: > A simple patch for updating the comment for the `InstanceKlass::set_classpath_index()` function. This pull request has now been integrated. Changeset: 461a3fee Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/461a3feebedccbf83bf3871d65ed7f2d1ad79307 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8261478: InstanceKlass::set_classpath_index does not match comments Reviewed-by: minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/4170 From dholmes at openjdk.java.net Tue May 25 01:14:01 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 01:14:01 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Mon, 24 May 2021 16:06:23 GMT, Daniel D. Daugherty wrote: > Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable > so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). > Also refactor common hash table size calculation code into static hash_table_size() > function and call it from both places. > > Test with Mach5 Tier[1-7] testing. Hi Dan, What is the motivation behind this? What do we see happen with the current HT if we have too many threads? What will happen with the new HT when it has to resize - will we see a pause while that happens? The mechanics of the change seem okay. A couple of queries on ergonomics choices. Thanks, David src/hotspot/share/runtime/threadSMR.cpp line 204: > 202: // "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from: > 203: // KVHashtable(void* const&)), &(bool primitive_equals(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o > 204: // We don't need these details in the comment. src/hotspot/share/runtime/threadSMR.cpp line 854: > 852: > 853: // Hash table size should be first power of two higher than twice the > 854: // length of the ThreadsList What is the basis for this? Seems reasonable for small numbers of threads but excessive for large numbers. src/hotspot/share/runtime/threadSMR.cpp line 857: > 855: static int hash_table_size() { > 856: ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list(); > 857: int hash_table_size = MIN2((int)threads->length(), 32) << 1; Doesn't this start things off a bit small. If the old size was 1031 why not start in that area? ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dholmes at openjdk.java.net Tue May 25 01:21:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 01:21:06 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends In-Reply-To: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Mon, 24 May 2021 15:18:00 GMT, Albert Mingkun Yang wrote: > Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. Hi Albert, Thanks for fixing this. A couple of nits on the details. David src/hotspot/share/runtime/thread.hpp line 1593: > 1591: > 1592: inline WorkerThread* Thread::as_Worker_thread() const { > 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); More than dubious I would say, just plain wrong. src/hotspot/share/runtime/thread.hpp line 1594: > 1592: inline WorkerThread* Thread::as_Worker_thread() const { > 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); > 1594: return (WorkerThread*)this; Can you use static_cast here rather the C-style cast please. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4167 From rehn at openjdk.java.net Tue May 25 06:35:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:35:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:28:15 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405: > >> 403: >> 404: guarantee(self == _owner, "invariant"); >> 405: guarantee(save == _recursions, "invariant"); > > Since you just restored the `_recursions` field on L402, why do > you need this guarantee() 2 code lines later? I left it since if we do changes here those two should be true even after any changes. I can remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 06:43:12 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:43:12 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 17:44:33 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > >> 210: _thread->frame_anchor()->make_walkable(_thread); >> 211: OrderAccess::storestore(); >> 212: _thread->set_thread_state(_thread_in_native); > > Please add a comment to the `storestore()` call: > // Keep thread_state change and make_walkable() separate. Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251: > >> 249: thread->frame_anchor()->make_walkable(thread); >> 250: OrderAccess::storestore(); >> 251: thread->set_thread_state(_thread_blocked); > > Please add a comment to the storestore() call: > // Keep thread_state change and make_walkable() separate. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From ayang at openjdk.java.net Tue May 25 06:43:46 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 25 May 2021 06:43:46 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v2] In-Reply-To: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: > Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4167/files - new: https://git.openjdk.java.net/jdk/pull/4167/files/e180c729..de74ee24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4167&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4167&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4167.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4167/head:pull/4167 PR: https://git.openjdk.java.net/jdk/pull/4167 From ayang at openjdk.java.net Tue May 25 06:43:51 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 25 May 2021 06:43:51 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v2] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: <0qHNwP6Ml2qsi-uwQWKuv8Hnr-RP_Cxuj3r917vzjeg=.4d5437d3-a7fc-4ed6-b848-e42172ee999e@github.com> On Tue, 25 May 2021 01:17:16 GMT, David Holmes wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/runtime/thread.hpp line 1593: > >> 1591: >> 1592: inline WorkerThread* Thread::as_Worker_thread() const { >> 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); > > More than dubious I would say, just plain wrong. Fixed. > src/hotspot/share/runtime/thread.hpp line 1594: > >> 1592: inline WorkerThread* Thread::as_Worker_thread() const { >> 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); >> 1594: return (WorkerThread*)this; > > Can you use static_cast here rather the C-style cast please. I get an compiling error, `static_cast from 'const Thread *' to 'WorkerThread *', which are not related by inheritance, is not allowed`. As `WorkerThread` is only declared in this context, the compiler doesn't know the inheritance relation here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From rehn at openjdk.java.net Tue May 25 06:49:16 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:49:16 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 17:57:44 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/runtime/objectMonitor.cpp line 451: > >> 449: // We cleared the pending monitor info since we've just gotten past >> 450: // the enter-check-for-suspend dance and we now own the monitor free >> 451: // and clear, i.e., it is no longer pending. > > This comment explains why the set-pending-to-NULL code was here > (outside the loop). You moved the code, but now the comment is > misplaced and the code no longer works the same. > > Update: I found this resolved comment below: > > And I set current->set_current_pending_monitor(om); to OM again > in ExitOnSuspend if we exit the OM. > > so that explains why we don't have a big change in behavior. > > However, I think you still need to do something about this comment. > > There is still an observable change in behavior in that the current > pending monitor can cycle between set->NULL->set->NULL when > we run into a suspend request. Previously, it did not cycle. If we stop for a suspend request current pending monitor will always be set, so the cycling cannot be seen. Updated comment(s). ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Tue May 25 06:51:00 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 May 2021 16:51:00 +1000 Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v2] In-Reply-To: <0qHNwP6Ml2qsi-uwQWKuv8Hnr-RP_Cxuj3r917vzjeg=.4d5437d3-a7fc-4ed6-b848-e42172ee999e@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> <0qHNwP6Ml2qsi-uwQWKuv8Hnr-RP_Cxuj3r917vzjeg=.4d5437d3-a7fc-4ed6-b848-e42172ee999e@github.com> Message-ID: <6264f7a7-8d37-9660-40a4-d785f08798de@oracle.com> On 25/05/2021 4:43 pm, Albert Mingkun Yang wrote: > On Tue, 25 May 2021 01:17:16 GMT, David Holmes wrote: > >>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >>> >>> review >> >> src/hotspot/share/runtime/thread.hpp line 1593: >> >>> 1591: >>> 1592: inline WorkerThread* Thread::as_Worker_thread() const { >>> 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); >> >> More than dubious I would say, just plain wrong. > > Fixed. Thanks. >> src/hotspot/share/runtime/thread.hpp line 1594: >> >>> 1592: inline WorkerThread* Thread::as_Worker_thread() const { >>> 1593: assert(is_Worker_thread(), "Dubious cast to WorkerThread*?"); >>> 1594: return (WorkerThread*)this; >> >> Can you use static_cast here rather the C-style cast please. > > I get an compiling error, `static_cast from 'const Thread *' to 'WorkerThread *', which are not related by inheritance, is not allowed`. As `WorkerThread` is only declared in this context, the compiler doesn't know the inheritance relation here. Ah I see. That is a downside of moving the NJT declarations to nonJavaThread.hpp :( Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4167 > From dholmes at openjdk.java.net Tue May 25 06:54:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 06:54:07 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v2] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Tue, 25 May 2021 06:43:46 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From rehn at openjdk.java.net Tue May 25 07:06:58 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 07:06:58 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Fixes for Dan - Merge branch 'master' into 8265753 - Final fixes: last famous words - Review fixes 2 - Merge branch 'master' into 8265753 - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/cc15431e..30d62e85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=05-06 Stats: 9596 lines in 1190 files changed: 4469 ins; 2824 del; 2303 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 07:12:08 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 07:12:08 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 18:12:00 GMT, Daniel D. Daugherty wrote: > Thumbs up. > > I just have some minor questions about a couple of the details. > Nothing blocking. Thanks Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 07:55:07 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 07:55:07 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Mon, 24 May 2021 16:06:23 GMT, Daniel D. Daugherty wrote: > Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable > so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). > Also refactor common hash table size calculation code into static hash_table_size() > function and call it from both places. > > Test with Mach5 Tier[1-7] testing. Marked as reviewed by rehn (Reviewer). Hi Dan, it looks like someone confused x-macros and templates. The issue is that there is code in the CPP file which requires expansion, so when compiling the CPP file it must know all templates instances.... the CPP should removed! This is the temporary fix until we have removed that CPP file. diff --git a/src/hotspot/share/runtime/threadSMR.cpp b/src/hotspot/share/runtime/threadSMR.cpp index f08320a9a95..c1daf26e7da 100644 --- a/src/hotspot/share/runtime/threadSMR.cpp +++ b/src/hotspot/share/runtime/threadSMR.cpp @@ -195,13 +195,3 @@ class ThreadScanHashtable : public CHeapObj { int _table_size; - // Note: I want this to be mtThread, but that causes linkage errors: - // - // Undefined symbols for architecture x86_64: - // "BasicHashtable<(MEMFLAGS)2>::free_buckets()", referenced from: - // ThreadsSMRSupport::free_list(ThreadsList*) in threadSMR.o - // ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread*) in threadSMR.o - // "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from: - // KVHashtable(void* const&)), &(bool primitive_equals(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o - // - // so I'm using mtInternal instead. - KVHashtable _ptrs; diff --git a/src/hotspot/share/utilities/hashtable.cpp b/src/hotspot/share/utilities/hashtable.cpp index c3c62e4c20b..0b0d3de72af 100644 --- a/src/hotspot/share/utilities/hashtable.cpp +++ b/src/hotspot/share/utilities/hashtable.cpp @@ -281,2 +281,3 @@ template class BasicHashtable; template class BasicHashtable; +template class BasicHashtable; ``` Thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From ngasson at openjdk.java.net Tue May 25 08:20:16 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 25 May 2021 08:20:16 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v5] In-Reply-To: References: Message-ID: <9iau55DjSdv3awUd0ZdB8lIwjdznhnCl-q5JZrcplG8=.ebdff3ef-fc1e-4204-8418-d2d320ab4cd1@github.com> On Sun, 23 May 2021 23:14:08 GMT, David Holmes wrote: >> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >> >> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into jep-306 > - The code for strict handling only applies to doubles. > - Add missing space > - lir_div_strictfp and lir_mul_strictfp > - Removed divDPR_reg_round as it has a false predicate and so is now unused > - Revert classFileParser changes as they will be handled by JDK-8266530 > - 8266530: HotSpot changes for JEP 306 > All methods are now implicitly strictfp so all code generation etc > uses the strict form. > There are still some names that include "strict" that could potentially > be renamed to rmeove it, but the fact we have to have strict fp semantics > is still important on some platforms, so the names help reinforce that IMO. src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 427: > 425: LIR_Opr tmp = LIR_OprFact::illegalOpr; > 426: if (x->op() == Bytecodes::_dmul || x->op() == Bytecodes::_ddiv) { > 427: tmp = new_register(T_DOUBLE); This variable `tmp` doesn't seem to be used. I guess this code originally came from x86 where it's passed through to `arithmetic_op_fpu()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3991 From david.holmes at oracle.com Tue May 25 09:35:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 May 2021 19:35:29 +1000 Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v5] In-Reply-To: <9iau55DjSdv3awUd0ZdB8lIwjdznhnCl-q5JZrcplG8=.ebdff3ef-fc1e-4204-8418-d2d320ab4cd1@github.com> References: <9iau55DjSdv3awUd0ZdB8lIwjdznhnCl-q5JZrcplG8=.ebdff3ef-fc1e-4204-8418-d2d320ab4cd1@github.com> Message-ID: <9fd04f3c-b667-69ea-80ac-bd5f885dad4e@oracle.com> On 25/05/2021 6:20 pm, Nick Gasson wrote: > On Sun, 23 May 2021 23:14:08 GMT, David Holmes wrote: > >>> As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. >>> >>> There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp line 427: > >> 425: LIR_Opr tmp = LIR_OprFact::illegalOpr; >> 426: if (x->op() == Bytecodes::_dmul || x->op() == Bytecodes::_ddiv) { >> 427: tmp = new_register(T_DOUBLE); > > This variable `tmp` doesn't seem to be used. I guess this code originally came from x86 where it's passed through to `arithmetic_op_fpu()`. Well spotted Nick. I've removed this dead code and am re-testing. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3991 > From dholmes at openjdk.java.net Tue May 25 09:37:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 09:37:28 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v6] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Remove dead code on aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/4dcab9b7..cc526aa4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From github.com+16811675+linade at openjdk.java.net Tue May 25 11:39:53 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Tue, 25 May 2021 11:39:53 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. I see that Robbin has updated 8262443 (Thanks Robbin). Are we clear to proceed? : ) ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From akozlov at openjdk.java.net Tue May 25 11:57:39 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 25 May 2021 11:57:39 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file Message-ID: Please review a small change that adds an option to GC.heap_dump to use an existing file. The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. Reviews of the CSR linked to the bug would be appreciated as well. ------------- Commit messages: - Add jcmd GC.head_dump -rewrite Changes: https://git.openjdk.java.net/jdk/pull/4183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267666 Stats: 12 lines in 6 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183 PR: https://git.openjdk.java.net/jdk/pull/4183 From rrich at openjdk.java.net Tue May 25 13:08:06 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 25 May 2021 13:08:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Still looks good to me. Cheer's, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From coleenp at openjdk.java.net Tue May 25 13:37:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 13:37:11 GMT Subject: RFR: 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 Message-ID: Fix the table to obsolete the option in the next release, when there'll be more Panama. Tested with tier1 in progress. ------------- Commit messages: - 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 Changes: https://git.openjdk.java.net/jdk/pull/4185/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4185&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267691 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4185.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4185/head:pull/4185 PR: https://git.openjdk.java.net/jdk/pull/4185 From rehn at openjdk.java.net Tue May 25 13:38:03 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 13:38:03 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: <375JabqE79ZBg7y-VsUTkHoex6Bou-NKSJyZvcfR-mY=.3e38489a-0e46-4828-92e2-2451508f0a63@github.com> On Tue, 25 May 2021 13:04:46 GMT, Richard Reingruber wrote: > Still looks good to me. > > Cheer's, Richard. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dcubed at openjdk.java.net Tue May 25 14:10:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 14:10:57 GMT Subject: RFR: 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core In-Reply-To: References: Message-ID: On Tue, 25 May 2021 00:40:28 GMT, David Holmes wrote: > Please review this trivial test fix to add -XX:-CreateCoredumpOnCrash to the exec'd VM that we expect to crash with SIGILL. If the core dump is generated it can take a long time on macos and cause the whole test to timeout. > > Testing: ran 50x on macos-x64, plus local linux-x64 > > Thanks, > David Thumbs up! I agree that this is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4177 From dcubed at openjdk.java.net Tue May 25 19:38:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 19:38:37 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <782cgh3spmJQbY7K27GMf1nGneF682wTAUoCQSSVHnc=.37c5c3cc-02e2-497d-85e7-78cd80e8809b@github.com> On Tue, 25 May 2021 01:01:15 GMT, David Holmes wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > src/hotspot/share/runtime/threadSMR.cpp line 204: > >> 202: // "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from: >> 203: // KVHashtable(void* const&)), &(bool primitive_equals(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o >> 204: // > > We don't need these details in the comment. True, but they served their purpose! I'm going to check out the fix that @robehn posted about how to get past this compilation issue. > src/hotspot/share/runtime/threadSMR.cpp line 854: > >> 852: >> 853: // Hash table size should be first power of two higher than twice the >> 854: // length of the ThreadsList > > What is the basis for this? Seems reasonable for small numbers of threads but excessive for large numbers. This is where we need @fisk. This comment and the associated code was written by @fisk in the early days of the Thread-SMR project. So we need Erik to go spelunking in the recesses of his memory for why he sized things this way... Also, I think the comment is a bit wrong and doesn't match the code below. > src/hotspot/share/runtime/threadSMR.cpp line 857: > >> 855: static int hash_table_size() { >> 856: ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list(); >> 857: int hash_table_size = MIN2((int)threads->length(), 32) << 1; > > Doesn't this start things off a bit small. If the old size was 1031 why not start in that area? We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project. The 1031 came from me and I stole it from some other fixed hash table size in the VM. Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads and `32 << 1` => `64`. Yeah, we really need @fisk to chime in here. Also, don't forget that these hash_tables are very, very short lived since they only exist while we are gathering either hazard ptrs or JavaThread* protected by hazard ptrs. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 19:45:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 19:45:38 GMT Subject: RFR: 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 In-Reply-To: References: Message-ID: On Tue, 25 May 2021 13:30:16 GMT, Coleen Phillimore wrote: > Fix the table to obsolete the option in the next release, when there'll be more Panama. > Tested with tier1 in progress. Thanks Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/4185 From coleenp at openjdk.java.net Tue May 25 19:45:39 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 19:45:39 GMT Subject: Integrated: 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 In-Reply-To: References: Message-ID: On Tue, 25 May 2021 13:30:16 GMT, Coleen Phillimore wrote: > Fix the table to obsolete the option in the next release, when there'll be more Panama. > Tested with tier1 in progress. This pull request has now been integrated. Changeset: c20ca42e Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/c20ca42e62a0a7419c04ff95087c7c2b4d2e0335 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/4185 From dcubed at openjdk.java.net Tue May 25 19:48:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 19:48:37 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <_NjaKrc0NORMBHDyQqAEsGE5dTm0TK-2nkH8e6WiW_4=.f6305ff9-b6a4-4fb1-98c3-420098d41328@github.com> On Tue, 25 May 2021 01:10:37 GMT, David Holmes wrote: > What is the motivation behind this? Finishing code that was left incomplete by the Thread-SMR project. We either get rid of the hash_table_size calculations (from two places) in the base code or we switch to a Hashtable that supports specifying a size at runtime instead of compile time. > What do we see happen with the current HT if we have too many threads? We haven't seen any problems with the current code. I'm just cleaning up this long standing piece of work. > What will happen with the new HT when it has to resize - will we see a > pause while that happens? These Thread-SMR hash tables don't resize. They are created and live for a very short time. They contain either hazard ptrs or they contain JavaThread* that are protected by hazard ptrs. ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the current hazard ptrs (there typically are not very many of these). ThreadsSMRSupport::is_a_protected_JavaThread() creates a ThreadScanHashtable of JavaThread* that are protected by the current hazard ptr in use by the system. Both of these ThreadScanHashtable objects only live as long as the function that created them, i.e., not long. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Tue May 25 19:48:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 19:48:37 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 07:51:39 GMT, Robbin Ehn wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Hi Dan, it looks like someone confused x-macros and templates. The issue is that there is code in the CPP file which requires expansion, so when compiling the CPP file it must know all templates instances.... the CPP should removed! > > This is the temporary fix until we have removed that CPP file. > > diff --git a/src/hotspot/share/runtime/threadSMR.cpp b/src/hotspot/share/runtime/threadSMR.cpp > index f08320a9a95..c1daf26e7da 100644 > --- a/src/hotspot/share/runtime/threadSMR.cpp > +++ b/src/hotspot/share/runtime/threadSMR.cpp > @@ -195,13 +195,3 @@ class ThreadScanHashtable : public CHeapObj { > int _table_size; > - // Note: I want this to be mtThread, but that causes linkage errors: > - // > - // Undefined symbols for architecture x86_64: > - // "BasicHashtable<(MEMFLAGS)2>::free_buckets()", referenced from: > - // ThreadsSMRSupport::free_list(ThreadsList*) in threadSMR.o > - // ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread*) in threadSMR.o > - // "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from: > - // KVHashtable(void* const&)), &(bool primitive_equals(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o > - // > - // so I'm using mtInternal instead. > - KVHashtable + KVHashtable &ThreadScanHashtable::ptr_equals> _ptrs; > diff --git a/src/hotspot/share/utilities/hashtable.cpp b/src/hotspot/share/utilities/hashtable.cpp > index c3c62e4c20b..0b0d3de72af 100644 > --- a/src/hotspot/share/utilities/hashtable.cpp > +++ b/src/hotspot/share/utilities/hashtable.cpp > @@ -281,2 +281,3 @@ template class BasicHashtable; > template class BasicHashtable; > +template class BasicHashtable; > > ``` > > Thanks, Robbin @robehn - Thanks for fix. I'll take it for a spin right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Tue May 25 19:52:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 19:52:38 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 01:10:37 GMT, David Holmes wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Hi Dan, > > What is the motivation behind this? What do we see happen with the current HT if we have too many threads? What will happen with the new HT when it has to resize - will we see a pause while that happens? > > The mechanics of the change seem okay. A couple of queries on ergonomics choices. > > Thanks, > David @dholmes-ora and @robehn - Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From hseigel at openjdk.java.net Tue May 25 20:26:33 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 25 May 2021 20:26:33 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests In-Reply-To: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Thu, 13 May 2021 10:14:24 GMT, Vladimir Ivanov wrote: > Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. > > In particular: > - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; > - pass `TestBuilder` as a parameter and initiate test execution from executor; > - switch max class file version tested from 52 to 61 (`V17`); > - minor changes (cleanups, new test cases) > > Testing: > - [x] vmTestbase/vm/runtime/defmeth/ > - [x] hs-tier5-rt - hs-tier8-rt JEP 306 (JDK-8175916) proposes removing ACC_STRICT for class file versions >= 61. See also https://github.com/openjdk/jdk/pull/3891. So perhaps testing of ACC_STRICT should be removed from these tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/4008 From dcubed at openjdk.java.net Tue May 25 20:39:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 20:39:56 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: > Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable > so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). > Also refactor common hash table size calculation code into static hash_table_size() > function and call it from both places. > > Test with Mach5 Tier[1-7] testing. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: rehn CR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4168/files - new: https://git.openjdk.java.net/jdk/pull/4168/files/2ca28ada..0e4db022 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4168&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4168&range=00-01 Stats: 12 lines in 2 files changed: 1 ins; 10 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4168/head:pull/4168 PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 20:39:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 20:39:56 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <3B6lz7mXlug3wOmjSo8QlBwJBQbD1seFUr1CPHM8fXc=.5962bb31-8056-4d93-b1cf-73dfa898e68f@github.com> On Tue, 25 May 2021 20:36:26 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR I think you updated it to fix the mtThread problem, while I was reviewing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 20:39:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 20:39:57 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: <782cgh3spmJQbY7K27GMf1nGneF682wTAUoCQSSVHnc=.37c5c3cc-02e2-497d-85e7-78cd80e8809b@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <782cgh3spmJQbY7K27GMf1nGneF682wTAUoCQSSVHnc=.37c5c3cc-02e2-497d-85e7-78cd80e8809b@github.com> Message-ID: On Tue, 25 May 2021 19:25:21 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/threadSMR.cpp line 204: >> >>> 202: // "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from: >>> 203: // KVHashtable(void* const&)), &(bool primitive_equals(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o >>> 204: // >> >> We don't need these details in the comment. > > True, but they served their purpose! I'm going to check out the fix > that @robehn posted about how to get past this compilation issue. I don't think you should have these comments either. They don't really help me understand why you get this compilation error. It seems like a TODO. Maybe the mtThread instantiation is missing from hashtable.cpp? >> src/hotspot/share/runtime/threadSMR.cpp line 854: >> >>> 852: >>> 853: // Hash table size should be first power of two higher than twice the >>> 854: // length of the ThreadsList >> >> What is the basis for this? Seems reasonable for small numbers of threads but excessive for large numbers. > > This is where we need @fisk. This comment and the associated code was > written by @fisk in the early days of the Thread-SMR project. So we need > Erik to go spelunking in the recesses of his memory for why he sized things > this way... > > Also, I think the comment is a bit wrong and doesn't match the code below. The theory in the code for KVHashtable or BasicHashtable is that it works better for prime numbers. It'll resize to other prime numbers if needed. I assume starting with 1007 should work fine, if the number of entries matches the number of threads. const int _small_table_sizes[] = { 107, 1009, 2017, 4049, 5051, 10103, 20201, 40423 } ; These are the resizing sizes in hashtable.cpp. Edit: You could use this table to choose an initial size based on your current number of threads. >> src/hotspot/share/runtime/threadSMR.cpp line 857: >> >>> 855: static int hash_table_size() { >>> 856: ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list(); >>> 857: int hash_table_size = MIN2((int)threads->length(), 32) << 1; >> >> Doesn't this start things off a bit small. If the old size was 1031 why not start in that area? > > We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project. > > The 1031 came from me and I stole it from some other fixed hash table size in the VM. > > Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out > at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads > and `32 << 1` => `64`. > > Yeah, we really need @fisk to chime in here. > > Also, don't forget that these hash_tables are very, very short lived > since they only exist while we are gathering either hazard ptrs or > JavaThread* protected by hazard ptrs. Yes, 32 doesn't seem right. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Tue May 25 20:49:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 20:49:37 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: <3B6lz7mXlug3wOmjSo8QlBwJBQbD1seFUr1CPHM8fXc=.5962bb31-8056-4d93-b1cf-73dfa898e68f@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <3B6lz7mXlug3wOmjSo8QlBwJBQbD1seFUr1CPHM8fXc=.5962bb31-8056-4d93-b1cf-73dfa898e68f@github.com> Message-ID: On Tue, 25 May 2021 20:35:08 GMT, Coleen Phillimore wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> rehn CR > > I think you updated it to fix the mtThread problem, while I was reviewing this. @coleenp - Thanks for the review! And sorry for changing the PR while you were reviewing... We definitely need to hear from @fisk on this PR... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Tue May 25 20:53:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 20:53:34 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 20:39:56 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR BTW, I suspect @fisk's choice of a max hash_table_size of 64 is due to his hash function: static unsigned int ptr_hash(void * const& s1) { // 2654435761 = 2^32 * Phi (golden ratio) return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 20:58:33 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 20:58:33 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 20:39:56 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR I didn't review this very carefully. I don't see where you free the hashtables. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Tue May 25 21:08:35 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 21:08:35 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 20:39:56 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR Here's where they are allocated and deleted: void ThreadsSMRSupport::free_list(ThreadsList* threads) { ThreadScanHashtable *scan_table = new ThreadScanHashtable(hash_table_size()); delete scan_table; } bool ThreadsSMRSupport::is_a_protected_JavaThread(JavaThread *thread) { ThreadScanHashtable *scan_table = new ThreadScanHashtable(hash_table_size()); delete scan_table; return thread_is_protected; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 21:22:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 21:22:34 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 20:39:56 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR Changes requested by coleenp (Reviewer). src/hotspot/share/runtime/threadSMR.cpp line 205: > 203: > 204: ~ThreadScanHashtable() { > 205: log_trace(thread, smr)("tid=" UINTX_FORMAT ": deallocate ThreadScanHashtable(%d) at " INTPTR_FORMAT, os::current_thread_id(), _table_size, p2i(this)); For a CHeap hashtable, I believe this should do this (or have KVHash have an API to delete all the entries). Dictionary::~Dictionary() { DictionaryEntry* probe = NULL; for (int index = 0; index < table_size(); index++) { for (DictionaryEntry** p = bucket_addr(index); *p != NULL; ) { probe = *p; *p = probe->next(); free_entry(probe); } } assert(number_of_entries() == 0, "should have removed all entries"); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 21:22:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 21:22:35 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 21:18:33 GMT, Coleen Phillimore wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> rehn CR > > src/hotspot/share/runtime/threadSMR.cpp line 205: > >> 203: >> 204: ~ThreadScanHashtable() { >> 205: log_trace(thread, smr)("tid=" UINTX_FORMAT ": deallocate ThreadScanHashtable(%d) at " INTPTR_FORMAT, os::current_thread_id(), _table_size, p2i(this)); > > For a CHeap hashtable, I believe this should do this (or have KVHash have an API to delete all the entries). > Dictionary::~Dictionary() { > DictionaryEntry* probe = NULL; > for (int index = 0; index < table_size(); index++) { > for (DictionaryEntry** p = bucket_addr(index); *p != NULL; ) { > probe = *p; > *p = probe->next(); > free_entry(probe); > } > } > assert(number_of_entries() == 0, "should have removed all entries"); > } This should be added to KVHashtable because it would be nice to migrate the other hashtables to this nicer API. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From coleenp at openjdk.java.net Tue May 25 21:35:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 25 May 2021 21:35:34 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 21:19:58 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/threadSMR.cpp line 205: >> >>> 203: >>> 204: ~ThreadScanHashtable() { >>> 205: log_trace(thread, smr)("tid=" UINTX_FORMAT ": deallocate ThreadScanHashtable(%d) at " INTPTR_FORMAT, os::current_thread_id(), _table_size, p2i(this)); >> >> For a CHeap hashtable, I believe this should do this (or have KVHash have an API to delete all the entries). >> Dictionary::~Dictionary() { >> DictionaryEntry* probe = NULL; >> for (int index = 0; index < table_size(); index++) { >> for (DictionaryEntry** p = bucket_addr(index); *p != NULL; ) { >> probe = *p; >> *p = probe->next(); >> free_entry(probe); >> } >> } >> assert(number_of_entries() == 0, "should have removed all entries"); >> } > > This should be added to KVHashtable because it would be nice to migrate the other hashtables to this nicer API. I don't see how the entries in the table are freed (in any of the KVHashtables). Maybe I'm missing something. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From cjplummer at openjdk.java.net Tue May 25 21:43:21 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 25 May 2021 21:43:21 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. @AntonKozlov I thought there was recently a thread were you discussed this, but I can't find it. If there was one, can you include a link? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From hseigel at openjdk.java.net Tue May 25 21:53:29 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 25 May 2021 21:53:29 GMT Subject: RFR: 8267691: Change table to obsolete CriticalJNINatives in JDK 18, not 17 In-Reply-To: References: Message-ID: <-AKwuvLo6xZB2gElQNc5DUHRvGdRo_LOI1OdDhfDjDs=.08cd7e12-53b1-42f4-9676-944cd6d60b96@github.com> On Tue, 25 May 2021 13:30:16 GMT, Coleen Phillimore wrote: > Fix the table to obsolete the option in the next release, when there'll be more Panama. > Tested with tier1 in progress. Looks good and trivial. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4185 From dcubed at openjdk.java.net Tue May 25 21:55:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 25 May 2021 21:55:03 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <60e3Lwgc_93h2eSPAnXbjH9H8hOwBhxjMKbdE0_9rbk=.fdb70b40-1749-4a60-80f0-c5de951a1efa@github.com> On Tue, 25 May 2021 21:32:56 GMT, Coleen Phillimore wrote: >> This should be added to KVHashtable because it would be nice to migrate the other hashtables to this nicer API. > > I don't see how the entries in the table are freed (in any of the KVHashtables). Maybe I'm missing something. I'll take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From eosterlund at openjdk.java.net Tue May 25 21:55:14 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 25 May 2021 21:55:14 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <782cgh3spmJQbY7K27GMf1nGneF682wTAUoCQSSVHnc=.37c5c3cc-02e2-497d-85e7-78cd80e8809b@github.com> Message-ID: <0-b32i69PD5HuV9PydRUapptY5YcLb3W9WsVI0xz20Y=.521f7fda-bd93-4405-bbe8-cbfeb01828eb@github.com> On Tue, 25 May 2021 20:31:13 GMT, Coleen Phillimore wrote: >> This is where we need @fisk. This comment and the associated code was >> written by @fisk in the early days of the Thread-SMR project. So we need >> Erik to go spelunking in the recesses of his memory for why he sized things >> this way... >> >> Also, I think the comment is a bit wrong and doesn't match the code below. > > The theory in the code for KVHashtable or BasicHashtable is that it works better for prime numbers. It'll resize to other prime numbers if needed. I assume starting with 1007 should work fine, if the number of entries matches the number of threads. > > const int _small_table_sizes[] = { 107, 1009, 2017, 4049, 5051, 10103, 20201, 40423 } ; > These are the resizing sizes in hashtable.cpp. > > Edit: You could use this table to choose an initial size based on your current number of threads. > This is where we need @fisk. This comment and the associated code was > > written by @fisk in the early days of the Thread-SMR project. So we need > > Erik to go spelunking in the recesses of his memory for why he sized things > > this way... > > > > Also, I think the comment is a bit wrong and doesn't match the code below. I have a habit of sizing hash tables in this way to achieve the following: * The power of two table size means you can map to a bucket using hash & (size - 1), instead of the much more expensive hash % size. Modulo is several orders of magnitude more expensive to execute. * Make sure the average number of entries per bucket is not exceeding 1. Having said that, the first of those two reasons no longer applies; the more generic table logic we use nowadays uses modulo based bucket mapping I think. I probably had a more manually crafted table earlier where I used that property. It was quite a while ago, so I don't remember what happened with that. If I had to guess, I'd think @coleenp might have encouraged me to not implement yet another hash table, as we already have too many in general. >> We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project. >> >> The 1031 came from me and I stole it from some other fixed hash table size in the VM. >> >> Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out >> at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads >> and `32 << 1` => `64`. >> >> Yeah, we really need @fisk to chime in here. >> >> Also, don't forget that these hash_tables are very, very short lived >> since they only exist while we are gathering either hazard ptrs or >> JavaThread* protected by hazard ptrs. > > Yes, 32 doesn't seem right. > We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project. > > > > The 1031 came from me and I stole it from some other fixed hash table size in the VM. > > > > Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out > > at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads > > and `32 << 1` => `64`. > > > > Yeah, we really need @fisk to chime in here. > > > > Also, don't forget that these hash_tables are very, very short lived > > since they only exist while we are gathering either hazard ptrs or > > JavaThread* protected by hazard ptrs. > > I don't recognize the arbitrary 32 limit. If I did indeed write that (I have no recollection), then the only reason for it that I can think of is that hazard pointers are (or were?) very infrequent to encounter and that most of the time, we end up adding no entries at all to the table. And that it would be somehow wasteful to allocate large tables only to not put anything into it. But yeah, wouldn't mind getting rid of this arbitrary heuristic limit. I don't think it matters today. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From vlivanov at openjdk.java.net Tue May 25 22:06:45 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 25 May 2021 22:06:45 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: > Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. > > In particular: > - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; > - pass `TestBuilder` as a parameter and initiate test execution from executor; > - switch max class file version tested from 52 to 61 (`V17`); > - minor changes (cleanups, new test cases) > > Testing: > - [x] vmTestbase/vm/runtime/defmeth/ > - [x] hs-tier5-rt - hs-tier8-rt 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 seven additional commits since the last revision: - Merge branch 'master' into 8267095.defmeth - Remove ACC_STRICT-related code - Cleanup - Remove scenarios - FIXME removal - Fixes - TestBuilder as a parameter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4008/files - new: https://git.openjdk.java.net/jdk/pull/4008/files/80d37457..9406cdc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=00-01 Stats: 30924 lines in 1766 files changed: 14299 ins; 12028 del; 4597 mod Patch: https://git.openjdk.java.net/jdk/pull/4008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4008/head:pull/4008 PR: https://git.openjdk.java.net/jdk/pull/4008 From vlivanov at openjdk.java.net Tue May 25 22:11:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 25 May 2021 22:11:01 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Tue, 25 May 2021 22:06:45 GMT, Vladimir Ivanov wrote: >> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. >> >> In particular: >> - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; >> - pass `TestBuilder` as a parameter and initiate test execution from executor; >> - switch max class file version tested from 52 to 61 (`V17`); >> - minor changes (cleanups, new test cases) >> >> Testing: >> - [x] vmTestbase/vm/runtime/defmeth/ >> - [x] hs-tier5-rt - hs-tier8-rt > > 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 seven additional commits since the last revision: > > - Merge branch 'master' into 8267095.defmeth > - Remove ACC_STRICT-related code > - Cleanup > - Remove scenarios > - FIXME removal > - Fixes > - TestBuilder as a parameter Thanks for taking a look, Harold. > JEP 306 (JDK-8175916) proposes removing ACC_STRICT for class file versions >= 61. See also #3891. So perhaps testing of ACC_STRICT should be removed from these tests? Good point. I went ahead and removed all ACC_STRICT-related code. It could be kept for major version <= 60, but I don't see much sense in introducing additional test configuration. IMO testing `ACC_STRICT` / `ACC_SYNCHRONIZED` method flags has marginal value. ------------- PR: https://git.openjdk.java.net/jdk/pull/4008 From smarks at openjdk.java.net Tue May 25 22:26:43 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 25 May 2021 22:26:43 GMT Subject: RFR: 8267123: Remove RMI Activation Message-ID: This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). This is a fairly straightforward removal of this component. - Activation implementation classes removed - Activation tests removed - adjustments to various comments to remove references to Activation - adjustments to some code to remove special-case support for Activation from core RMI - adjustments to several tests to remove testing and support for, and mentions of Activation - remove `rmid` tool (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) ------------- Commit messages: - Merge branch 'master' into JDK-8267123-Remove-RMI-Activation - Merge branch 'master' into remove-rmi-activation - Clean up some old comments. - Small fixups. - First cut at removal of RMI Activation. Changes: https://git.openjdk.java.net/jdk/pull/4194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267123 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4194/head:pull/4194 PR: https://git.openjdk.java.net/jdk/pull/4194 From erikj at openjdk.java.net Tue May 25 22:41:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 25 May 2021 22:41:16 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From dholmes at openjdk.java.net Tue May 25 23:03:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:03:28 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Nothing further from me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Tue May 25 23:12:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:12:16 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. Okay by me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4028 From dholmes at openjdk.java.net Tue May 25 23:38:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:38:19 GMT Subject: RFR: 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core In-Reply-To: References: Message-ID: On Tue, 25 May 2021 00:40:28 GMT, David Holmes wrote: > Please review this trivial test fix to add -XX:-CreateCoredumpOnCrash to the exec'd VM that we expect to crash with SIGILL. If the core dump is generated it can take a long time on macos and cause the whole test to timeout. > > Testing: ran 50x on macos-x64, plus local linux-x64 > > Thanks, > David Thanks Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/4177 From dholmes at openjdk.java.net Tue May 25 23:38:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:38:19 GMT Subject: Integrated: 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core In-Reply-To: References: Message-ID: On Tue, 25 May 2021 00:40:28 GMT, David Holmes wrote: > Please review this trivial test fix to add -XX:-CreateCoredumpOnCrash to the exec'd VM that we expect to crash with SIGILL. If the core dump is generated it can take a long time on macos and cause the whole test to timeout. > > Testing: ran 50x on macos-x64, plus local linux-x64 > > Thanks, > David This pull request has now been integrated. Changeset: d0d2ddcc Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/d0d2ddccaf93a1f97843e7d01c5bf6eb8ba3aece Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8267651: runtime/handshake/HandshakeTimeoutTest.java times out when dumping core Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4177 From dholmes at openjdk.java.net Tue May 25 23:41:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:41:21 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: <0-b32i69PD5HuV9PydRUapptY5YcLb3W9WsVI0xz20Y=.521f7fda-bd93-4405-bbe8-cbfeb01828eb@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <782cgh3spmJQbY7K27GMf1nGneF682wTAUoCQSSVHnc=.37c5c3cc-02e2-497d-85e7-78cd80e8809b@github.com> <0-b32i69PD5HuV9PydRUapptY5YcLb3W9WsVI0xz20Y=.521f7fda-bd93-4405-bbe8-cbfeb01828eb@github.com> Message-ID: On Tue, 25 May 2021 21:48:48 GMT, Erik ?sterlund wrote: >> Yes, 32 doesn't seem right. > >> We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project. >> >> >> >> The 1031 came from me and I stole it from some other fixed hash table size in the VM. >> >> >> >> Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out >> >> at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads >> >> and `32 << 1` => `64`. >> >> >> >> Yeah, we really need @fisk to chime in here. >> >> >> >> Also, don't forget that these hash_tables are very, very short lived >> >> since they only exist while we are gathering either hazard ptrs or >> >> JavaThread* protected by hazard ptrs. >> >> > > I don't recognize the arbitrary 32 limit. If I did indeed write that (I have no recollection), then the only reason for it that I can think of is that hazard pointers are (or were?) very infrequent to encounter and that most of the time, we end up adding no entries at all to the table. And that it would be somehow wasteful to allocate large tables only to not put anything into it. > > But yeah, wouldn't mind getting rid of this arbitrary heuristic limit. I don't think it matters today. So the "dynamic" aspect of this is not a long-lived table that needs to grow/shrink, but simply that we want to size each short-lived table more appropriately rather than all being sized at 1031. Very unclear what potential performance implication of this change could be. ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From david.holmes at oracle.com Wed May 26 01:23:33 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 May 2021 11:23:33 +1000 Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: <_NjaKrc0NORMBHDyQqAEsGE5dTm0TK-2nkH8e6WiW_4=.f6305ff9-b6a4-4fb1-98c3-420098d41328@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <_NjaKrc0NORMBHDyQqAEsGE5dTm0TK-2nkH8e6WiW_4=.f6305ff9-b6a4-4fb1-98c3-420098d41328@github.com> Message-ID: <9a736801-6a32-dca5-05eb-5c2a55963857@oracle.com> Hi Dan, On 26/05/2021 5:48 am, Daniel D.Daugherty wrote: > On Tue, 25 May 2021 01:10:37 GMT, David Holmes wrote: > >> What is the motivation behind this? > > Finishing code that was left incomplete by the Thread-SMR project. We either > get rid of the hash_table_size calculations (from two places) in the base code > or we switch to a Hashtable that supports specifying a size at runtime instead > of compile time. Okay - removing the unused code would be a less disruptive change in that case. > >> What do we see happen with the current HT if we have too many threads? > > We haven't seen any problems with the current code. I'm just cleaning up this > long standing piece of work. > > >> What will happen with the new HT when it has to resize - will we see a >> pause while that happens? > > These Thread-SMR hash tables don't resize. They are created and live for > a very short time. They contain either hazard ptrs or they contain JavaThread* > that are protected by hazard ptrs. > > ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the > current hazard ptrs (there typically are not very many of these). > > ThreadsSMRSupport::is_a_protected_JavaThread() creates a > ThreadScanHashtable of JavaThread* that are protected by the > current hazard ptr in use by the system. > > Both of these ThreadScanHashtable objects only live as long as the > function that created them, i.e., not long. Okay I get the "dynamic" aspect of this now. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4168 > From coleenp at openjdk.java.net Wed May 26 01:40:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 26 May 2021 01:40:18 GMT Subject: RFR: 8267209: Child threads should defer logging to after child-parent handshake In-Reply-To: References: Message-ID: On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe wrote: > Hi, > > May I have reviews for this very simple change (triggered by this ML discussion [1]): > > On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake. > > The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake. > > I ran OPs [1] test on my machine and with logging to a very fast ssd enabled: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 5191 > > > with this patch test time drops by about 19%: > > > thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest > Duration: 4228 > > > No perceptible difference with logging disabled, as it should be. > > --- > > (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.) > > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html This looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4042 From coleenp at openjdk.java.net Wed May 26 02:05:15 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 26 May 2021 02:05:15 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: <60e3Lwgc_93h2eSPAnXbjH9H8hOwBhxjMKbdE0_9rbk=.fdb70b40-1749-4a60-80f0-c5de951a1efa@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> <60e3Lwgc_93h2eSPAnXbjH9H8hOwBhxjMKbdE0_9rbk=.fdb70b40-1749-4a60-80f0-c5de951a1efa@github.com> Message-ID: On Tue, 25 May 2021 21:51:50 GMT, Daniel D. Daugherty wrote: >> I don't see how the entries in the table are freed (in any of the KVHashtables). Maybe I'm missing something. > > I'll take a look. https://bugs.openjdk.java.net/browse/JDK-8267752 ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dholmes at openjdk.java.net Wed May 26 02:14:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 02:14:20 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Tue, 25 May 2021 22:06:45 GMT, Vladimir Ivanov wrote: >> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. >> >> In particular: >> - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; >> - pass `TestBuilder` as a parameter and initiate test execution from executor; >> - switch max class file version tested from 52 to 61 (`V17`); >> - minor changes (cleanups, new test cases) >> >> Testing: >> - [x] vmTestbase/vm/runtime/defmeth/ >> - [x] hs-tier5-rt - hs-tier8-rt > > 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 seven additional commits since the last revision: > > - Merge branch 'master' into 8267095.defmeth > - Remove ACC_STRICT-related code > - Cleanup > - Remove scenarios > - FIXME removal > - Fixes > - TestBuilder as a parameter Hi Vladimir, I took a scan through this huge change and things look okay to me. One thing we seem to have lost is the documentation for what this setup code: /* majorVer */ Set.of(MAX_MAJOR_VER), /* flags */ Set.of(0, ACC_SYNCHRONIZED), /* redefine */ Set.of(false, true), /* execMode */ Set.of(DIRECT, REFLECTION, INVOKE_EXACT, INVOKE_GENERIC, INVOKE_WITH_ARGS, INDY)); actually means. Also references to JVMS8 should probably just say JVMS. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4008 From jiefu at openjdk.java.net Wed May 26 03:00:29 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 03:00:29 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported Message-ID: Hi all, cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. This reason is that customized class loader is not supported on 32-bit systems [1]. It would be better to fix it. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 ------------- Commit messages: - 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported Changes: https://git.openjdk.java.net/jdk/pull/4198/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4198&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267754 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4198/head:pull/4198 PR: https://git.openjdk.java.net/jdk/pull/4198 From minqi at openjdk.java.net Wed May 26 03:46:17 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 26 May 2021 03:46:17 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported In-Reply-To: References: Message-ID: On Wed, 26 May 2021 02:53:09 GMT, Jie Fu wrote: > Hi all, > > cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. > This reason is that customized class loader is not supported on 32-bit systems [1]. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 Changes requested by minqi (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 113: > 111: appJar = ClassFileInstaller.writeJar("loader_constraints.jar", appClasses); > 112: doTest(); > 113: if (!Platform.isWindows() && Platform.is64bit()) { Platform.java has a function: Platform.areCustomLoadersSupportedForCDS(). You can use here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From jiefu at openjdk.java.net Wed May 26 04:08:35 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 04:08:35 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> > Hi all, > > cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. > This reason is that customized class loader is not supported on 32-bit systems [1]. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Use Platform.areCustomLoadersSupportedForCDS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4198/files - new: https://git.openjdk.java.net/jdk/pull/4198/files/095e7915..fe20d9f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4198&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4198&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4198.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4198/head:pull/4198 PR: https://git.openjdk.java.net/jdk/pull/4198 From jiefu at openjdk.java.net Wed May 26 04:08:36 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 04:08:36 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 03:42:43 GMT, Yumin Qi wrote: > Platform.java has a function: Platform.areCustomLoadersSupportedForCDS(). You can use here. Good suggestion! Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From minqi at openjdk.java.net Wed May 26 04:12:14 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 26 May 2021 04:12:14 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> Message-ID: On Wed, 26 May 2021 04:08:35 GMT, Jie Fu wrote: >> Hi all, >> >> cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. >> This reason is that customized class loader is not supported on 32-bit systems [1]. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.areCustomLoadersSupportedForCDS LGTM. Thanks for the fix. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4198 From dholmes at openjdk.java.net Wed May 26 04:44:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 04:44:12 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> Message-ID: <2gZ6ZBYdrrCzo8mOmfIcVfJOD6Gth4CyxYvzOeU0wGY=.404c2c55-7a08-44c2-9441-b64b2668cea1@github.com> On Wed, 26 May 2021 04:08:35 GMT, Jie Fu wrote: >> Hi all, >> >> cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. >> This reason is that customized class loader is not supported on 32-bit systems [1]. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.areCustomLoadersSupportedForCDS Hi Jie, Fix looks good. But there is a pre-existing nit: shouldn't there be an else that throws SkippedException so that we can see the test was skipped and not vacuously passed? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4198 From jiefu at openjdk.java.net Wed May 26 06:22:19 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 06:22:19 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: <2gZ6ZBYdrrCzo8mOmfIcVfJOD6Gth4CyxYvzOeU0wGY=.404c2c55-7a08-44c2-9441-b64b2668cea1@github.com> References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> <2gZ6ZBYdrrCzo8mOmfIcVfJOD6Gth4CyxYvzOeU0wGY=.404c2c55-7a08-44c2-9441-b64b2668cea1@github.com> Message-ID: On Wed, 26 May 2021 04:41:03 GMT, David Holmes wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Platform.areCustomLoadersSupportedForCDS > > Hi Jie, > > Fix looks good. But there is a pre-existing nit: shouldn't there be an else that throws SkippedException so that we can see the test was skipped and not vacuously passed? > > Thanks, > David Thanks @dholmes-ora for your review. > Hi Jie, > > Fix looks good. But there is a pre-existing nit: shouldn't there be an else that throws SkippedException so that we can see the test was skipped and not vacuously passed? > Got it. We didn't throw SkippedException for this test since it would run doTest [1] even on 32-bit systems. Thanks. [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java#L65 ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From alanb at openjdk.java.net Wed May 26 06:24:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 May 2021 06:24:22 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) One other test that might need an update is test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java, it might be just the summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From rehn at openjdk.java.net Wed May 26 06:24:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 26 May 2021 06:24:23 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 22:59:55 GMT, David Holmes wrote: > Nothing further from me. > > Thanks, > David Thank you David! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Wed May 26 07:43:01 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 May 2021 17:43:01 +1000 Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> <2gZ6ZBYdrrCzo8mOmfIcVfJOD6Gth4CyxYvzOeU0wGY=.404c2c55-7a08-44c2-9441-b64b2668cea1@github.com> Message-ID: <54c2dad4-61a9-1f9b-4ac7-28a6f12596f1@oracle.com> On 26/05/2021 4:22 pm, Jie Fu wrote: > On Wed, 26 May 2021 04:41:03 GMT, David Holmes wrote: > >>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Use Platform.areCustomLoadersSupportedForCDS >> >> Hi Jie, >> >> Fix looks good. But there is a pre-existing nit: shouldn't there be an else that throws SkippedException so that we can see the test was skipped and not vacuously passed? >> >> Thanks, >> David > > Thanks @dholmes-ora for your review. > >> Hi Jie, >> >> Fix looks good. But there is a pre-existing nit: shouldn't there be an else that throws SkippedException so that we can see the test was skipped and not vacuously passed? >> > > Got it. > > We didn't throw SkippedException for this test since it would run doTest [1] even on 32-bit systems. Got it. Sorry I misread the main method. Thanks, David > Thanks. > > [1] https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java#L65 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4198 > From iignatyev at openjdk.java.net Wed May 26 08:00:21 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 26 May 2021 08:00:21 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 04:05:44 GMT, Jie Fu wrote: >> test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java line 113: >> >>> 111: appJar = ClassFileInstaller.writeJar("loader_constraints.jar", appClasses); >>> 112: doTest(); >>> 113: if (!Platform.isWindows() && Platform.is64bit()) { >> >> Platform.java has a function: Platform.areCustomLoadersSupportedForCDS(). You can use here. > >> Platform.java has a function: Platform.areCustomLoadersSupportedForCDS(). You can use here. > > Good suggestion! > Updated. > Thanks. I think a better solution would be to split the test into two subtests (two separate jtreg test descriptions in one .java file): one for `doTest` another for `doTestCustomLoader` and use `@requires vm.cds.custom.loaders` in the 2nd one. this way, we will get more clear test results. Cheers, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From github.com+16811675+linade at openjdk.java.net Wed May 26 09:27:15 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Wed, 26 May 2021 09:27:15 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 06:18:56 GMT, Yude Lin wrote: >> Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. >> >> An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond >> >> I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. > > Yude Lin has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." > > This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. > - Revert "8266963: Reentrance condition for safepoint/handshake" > > This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. May I ask your help to sponsor? ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From akozlov at openjdk.java.net Wed May 26 09:37:13 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 26 May 2021 09:37:13 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance. I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From jiefu at openjdk.java.net Wed May 26 09:41:12 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 09:41:12 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 07:57:05 GMT, Igor Ignatyev wrote: > I think a better solution would be to split the test into two subtests (two separate jtreg test descriptions in one .java file): one for `doTest` another for `doTestCustomLoader` and use `@requires vm.cds.custom.loaders` in the 2nd one. this way, we will get more clear test results. > > Cheers, > -- Igor Thanks @iignatev for your review and sharing. I didn't know this skill before. Splitting the test into two subtests seems making a tiny bit sense since the CI/CD won't care which sub-tests are not run. I prefer the current (minimal) change since I think it's already good enough and I didn't find an easy way to rewrite it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From rehn at openjdk.java.net Wed May 26 10:34:17 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 26 May 2021 10:34:17 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 09:27:15 GMT, David Holmes wrote: >> Yude Lin has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert "8262443: GenerateOopMap::do_interpretation can spin for a long time." >> >> This reverts commit 7988c1d9aa7e3b990c17fdf5e31195e66e7fc5f2. >> - Revert "8266963: Reentrance condition for safepoint/handshake" >> >> This reverts commit aa1ba2353e28877217e23c00577427f4f2c001ca. > > Hold on a moment! This undoes 8262443, so what happens with the issue that bug was fixing? > > David Sorry I don't know how, I think @dholmes-ora and @zhengyu123 have much more experience with that. Can anyone of you help out? ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From dholmes at openjdk.java.net Wed May 26 12:30:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 12:30:16 GMT Subject: RFR: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue [v2] In-Reply-To: References: Message-ID: <5eYbC6pFxJEjeDWA6lJu4eqdbVpTIFp7s5WRZNL1lm4=.ada75def-adeb-4131-82ed-e792f7d08131@github.com> On Wed, 26 May 2021 10:31:48 GMT, Robbin Ehn wrote: >> Hold on a moment! This undoes 8262443, so what happens with the issue that bug was fixing? >> >> David > > Sorry I don't know how, I think @dholmes-ora and @zhengyu123 have much more experience with that. > Can anyone of you help out? @robehn You just enter /sponsor as a comment. I've done it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From github.com+16811675+linade at openjdk.java.net Wed May 26 12:30:17 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Wed, 26 May 2021 12:30:17 GMT Subject: Integrated: 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue In-Reply-To: References: Message-ID: On Fri, 14 May 2021 08:01:12 GMT, Yude Lin wrote: > Shenandoah hangs when running specjvm2008 derby. The reason is a Java Thread reenters safepoint/handshake and blocks on itself. Please checkout the bugid for more details. After discussion with @zhengyu123, we think this might not be Shenandoah-specific. I propose to add a check before processing the safepoint/handshake. > > An alternative approach (also insight from @zhengyu123) is to move the check a little earlier to the specific place where the Java Thread do ThreadBlockInVM. To feel reassured that no more reentrance exists in other places, I still leave the check in safepoint/handshake as debug code. See https://github.com/openjdk/jdk/compare/master...linade:reentrancecond > > I'd appreciate more of your thoughts on these as I understand it could be a rather critical part of the code. This pull request has now been integrated. Changeset: 9c346a1e Author: Yude Lin Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/9c346a1ec78b45c61fbfc76961dc5674cfd98520 Stats: 14 lines in 2 files changed: 2 ins; 9 del; 3 mod 8266963: Remove safepoint poll introduced in 8262443 due to reentrance issue Reviewed-by: rehn, zgu, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4028 From jiefu at openjdk.java.net Wed May 26 12:57:23 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 12:57:23 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default Message-ID: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> Hi all, NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. NUMA APIs depend on several syscalls. E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. But these dependent syscalls can be unsupported for various reasons. Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. So it's necessary to check whether the syscalls are available. In theory, all NUMA-related syscalls should be checked. But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. And this can be refined in the future if it turns out to be a problem. Thanks. Best regards, Jie [1] https://docs.docker.com/engine/security/seccomp/ ------------- Commit messages: - 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default Changes: https://git.openjdk.java.net/jdk/pull/4205/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4205&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241423 Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4205/head:pull/4205 PR: https://git.openjdk.java.net/jdk/pull/4205 From dholmes at openjdk.java.net Wed May 26 13:12:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 13:12:13 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default In-Reply-To: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> Message-ID: <5ekuGe1QkYHsqVVyyJO36qMWgXRnop0LkjEmfIPzLjM=.e2188979-e4f2-4bf7-88ba-65188dca9d5c@github.com> On Wed, 26 May 2021 12:49:34 GMT, Jie Fu wrote: > Hi all, > > NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. > > NUMA APIs depend on several syscalls. > E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. > But these dependent syscalls can be unsupported for various reasons. > Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. > So it's necessary to check whether the syscalls are available. > > In theory, all NUMA-related syscalls should be checked. > But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. > So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. > And this can be refined in the future if it turns out to be a problem. > > Thanks. > Best regards, > Jie > > [1] https://docs.docker.com/engine/security/seccomp/ Hi Jie, This wasn't as bad as I thought it might be. :) But I have one suggested change and a query. Thanks, David src/hotspot/os/linux/os_linux.cpp line 4482: > 4480: > 4481: // Check numa dependent syscalls > 4482: bool os::Linux::numa_syscall_check() { This can just be a static function in the file rather then being in the os::Linux "namespace" src/hotspot/os/linux/os_linux.cpp line 4489: > 4487: // others like mbind would cause unexpected side effects. > 4488: int dummy = 0; > 4489: if (syscall(SYS_get_mempolicy, &dummy, NULL, 0, (void*)&dummy, 3) == -1) { Is this SYS_get_mempolicy symbol guaranteed to be available on our supported Linux versions? See earlier in the file for how we handle SYS_gettid and SYS_getcpu. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4205 From hseigel at openjdk.java.net Wed May 26 13:20:28 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 26 May 2021 13:20:28 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Tue, 25 May 2021 22:06:45 GMT, Vladimir Ivanov wrote: >> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. >> >> In particular: >> - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; >> - pass `TestBuilder` as a parameter and initiate test execution from executor; >> - switch max class file version tested from 52 to 61 (`V17`); >> - minor changes (cleanups, new test cases) >> >> Testing: >> - [x] vmTestbase/vm/runtime/defmeth/ >> - [x] hs-tier5-rt - hs-tier8-rt > > 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 seven additional commits since the last revision: > > - Merge branch 'master' into 8267095.defmeth > - Remove ACC_STRICT-related code > - Cleanup > - Remove scenarios > - FIXME removal > - Fixes > - TestBuilder as a parameter This big cleanup looks good. I just had the one comment below about class file versions. Also, can you update the copyrights? Thanks, Harold test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java line 163: > 161: majorVerValues[i] = MIN_MAJOR_VER + i; > 162: } > 163: Does this mean that the stress tests will run for all class versions between JDK 1.5 and JDK 17 ? If so, maybe change it to just run for JDK 1.5, 11, and 17 releases? ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4008 From jiefu at openjdk.java.net Wed May 26 14:28:39 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 14:28:39 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> Message-ID: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> > Hi all, > > NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. > > NUMA APIs depend on several syscalls. > E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. > But these dependent syscalls can be unsupported for various reasons. > Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. > So it's necessary to check whether the syscalls are available. > > In theory, all NUMA-related syscalls should be checked. > But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. > So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. > And this can be refined in the future if it turns out to be a problem. > > Thanks. > Best regards, > Jie > > [1] https://docs.docker.com/engine/security/seccomp/ Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Remove os::Linux namespace for numa_syscall_check() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4205/files - new: https://git.openjdk.java.net/jdk/pull/4205/files/a40c9f1c..ea84a321 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4205&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4205&range=00-01 Stats: 31 lines in 2 files changed: 15 ins; 16 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4205.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4205/head:pull/4205 PR: https://git.openjdk.java.net/jdk/pull/4205 From jiefu at openjdk.java.net Wed May 26 14:28:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 14:28:40 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <5ekuGe1QkYHsqVVyyJO36qMWgXRnop0LkjEmfIPzLjM=.e2188979-e4f2-4bf7-88ba-65188dca9d5c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <5ekuGe1QkYHsqVVyyJO36qMWgXRnop0LkjEmfIPzLjM=.e2188979-e4f2-4bf7-88ba-65188dca9d5c@github.com> Message-ID: On Wed, 26 May 2021 13:04:30 GMT, David Holmes wrote: > This can just be a static function in the file rather then being in the os::Linux "namespace" Updated. Thanks. > Is this SYS_get_mempolicy symbol guaranteed to be available on our supported Linux versions? See earlier in the file for how we handle SYS_gettid and SYS_getcpu. I think it's OK to use the symbol directly since we have used it in ZGC [1]. Thanks. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/gc/z/zSyscall_linux.cpp#L39 ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From dcubed at openjdk.java.net Wed May 26 14:48:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 26 May 2021 14:48:24 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Thumbs up. Reviewed the incremental between v05 -> v06. Looks good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From pliden at openjdk.java.net Wed May 26 15:21:17 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 26 May 2021 15:21:17 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() Wasn't this fixed in https://github.com/openjdk/jdk/pull/3704? It seems we now have a similar check in two different places? ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From pchilanomate at openjdk.java.net Wed May 26 15:21:22 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 15:21:22 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 07:43:06 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: >> >>> 275: class ThreadBlockInVM { >>> 276: InFlightMutexRelease _ifmr; >>> 277: ThreadBlockInVMPreprocess _tbivmpp; >> >> Why delegate to the TBIVMPP instead of extending it? > > I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From jiefu at openjdk.java.net Wed May 26 15:31:15 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 15:31:15 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() > Wasn't this fixed in #3704? No. #3704 just fix the zgc crash. Other gcs still suffer from it. >It seems we now have a similar check in two different places? To fix the zgc crash, we only need to check `get_mempolicy`. But `numa_syscall_check` may be extended to other syscalls in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From pliden at openjdk.java.net Wed May 26 15:49:18 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 26 May 2021 15:49:18 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() But then we should remove the check in ZGC, since it serves no purpose anymore when the same check is done in `libnuma_init`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From iklam at openjdk.java.net Wed May 26 18:09:16 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 26 May 2021 18:09:16 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> Message-ID: On Wed, 26 May 2021 04:08:35 GMT, Jie Fu wrote: >> Hi all, >> >> cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. >> This reason is that customized class loader is not supported on 32-bit systems [1]. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.areCustomLoadersSupportedForCDS LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4198 From rriggs at openjdk.java.net Wed May 26 18:35:21 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:35:21 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From rehn at openjdk.java.net Wed May 26 18:35:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 26 May 2021 18:35:33 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 15:18:43 GMT, Patricio Chilano Mateo wrote: >> I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. > > Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? You mean revert your change of having the monitor as a parameter to ThreadBlockInVM? And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM? I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :) So I can open an RFE if you want? ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Wed May 26 18:50:51 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 18:50:51 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Marked as reviewed by pchilanomate (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Wed May 26 18:50:52 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 18:50:52 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <2EZdZ8P_QGnZuMmQtUdXmT2LhfY2p043OvLIARFjpb0=.0f89ec87-668d-46e0-bda0-cce14ddb2a37@github.com> On Wed, 26 May 2021 18:30:16 GMT, Robbin Ehn wrote: >> Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? > > You mean revert your change of having the monitor as a parameter to ThreadBlockInVM? > And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM? > I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :) > So I can open an RFE if you want? Right, so when we added the _in_flight_mutex_addr to TBIVM this was the only case where we would need to check a condition and execute some action, but now that we are doing it from objectMonitors and jvmtiRawMonitors too then it seems we should use it the same way here. Sure, we can do it in another RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From smarks at openjdk.java.net Wed May 26 19:49:04 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 May 2021 19:49:04 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: <6dMALeSEys26_TFkj3m4WSgOehMYVZuZzUHRQf9kp3I=.b3b00dab-9265-4522-88e6-fc0cb9593a3f@github.com> On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) AlanBateman wrote: > test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java Oh yes, this test mentions `rmid`, but it is basically a direct test of the `ReliableLog` stuff and it doesn't actually use or depend on Activation or `rmid`. The test still runs and passes. I'll do a followup pass to see if anything in the system uses anything in the `sun.rmi.log` package. Maybe the only user was Activation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From ayang at openjdk.java.net Wed May 26 20:31:20 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 26 May 2021 20:31:20 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: > Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - inline - tmp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4167/files - new: https://git.openjdk.java.net/jdk/pull/4167/files/de74ee24..56b1e17c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4167&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4167&range=01-02 Stats: 13 lines in 3 files changed: 7 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4167.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4167/head:pull/4167 PR: https://git.openjdk.java.net/jdk/pull/4167 From ayang at openjdk.java.net Wed May 26 20:31:21 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 26 May 2021 20:31:21 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v2] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Tue, 25 May 2021 06:43:46 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Moved the definition to the inline file so that `static_cast` can be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From mr at openjdk.java.net Wed May 26 20:59:13 2021 From: mr at openjdk.java.net (Mark Reinhold) Date: Wed, 26 May 2021 20:59:13 GMT Subject: Integrated: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals In-Reply-To: References: Message-ID: <9NYZ1R5LctYzlt6HwT2lWjSmUtWfbnwYpQYa4guwn0Q=.f2fc355a-d587-403b-94df-c9464346a68d@github.com> On Thu, 13 May 2021 17:14:36 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. This pull request has now been integrated. Changeset: e6302354 Author: Mark Reinhold URL: https://git.openjdk.java.net/jdk/commit/e63023546aaf48ae39c72ab37f6ef3f5474e19cc Stats: 2842 lines in 26 files changed: 0 ins; 2792 del; 50 mod 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals Co-authored-by: Alan Bateman Reviewed-by: mchung, alanb, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/4015 From dcubed at openjdk.java.net Wed May 26 22:23:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 26 May 2021 22:23:05 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v2] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Tue, 25 May 2021 20:39:56 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > rehn CR @fisk - Thanks for chiming in on this thread. @coleenp - I tried adding free_entries() support, but I wasn't able to get the code to build. Thanks for filing https://bugs.openjdk.java.net/browse/JDK-8267752 so someone can followup on KVHashtable entry freeing. @dholmes-ora - Agreed that I have no idea what the performance impact would be and I don't want to take the time to figure that out so I'm going to rewind and go the other route that has been discussed for this bug: - remove the unused hash_code_size calculations - leave the Thread-SMR hash table at 1031 elements since it has been that way since JDK10-B36 (integrated on 2017.11.24) ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From jiefu at openjdk.java.net Wed May 26 23:03:10 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 23:03:10 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> References: <0CEdg1NAJbNC9vNUO2vfRdLTwgbC3qhpnenz_m7uQzo=.b68a1a3a-842d-4d50-8a5b-ebcfeea26bc8@github.com> Message-ID: <20h5eZ8S6m5hF6Motq8iN2iJLIapKfbQPBxJFWp0H9g=.2df23c6b-eb7d-4e28-be8a-c567d21f7194@github.com> On Wed, 26 May 2021 04:08:35 GMT, Jie Fu wrote: >> Hi all, >> >> cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. >> This reason is that customized class loader is not supported on 32-bit systems [1]. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use Platform.areCustomLoadersSupportedForCDS Thank you all for your review and comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From jiefu at openjdk.java.net Wed May 26 23:03:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 26 May 2021 23:03:11 GMT Subject: Integrated: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported In-Reply-To: References: Message-ID: On Wed, 26 May 2021 02:53:09 GMT, Jie Fu wrote: > Hi all, > > cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32. > This reason is that customized class loader is not supported on 32-bit systems [1]. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/classListParser.cpp#L440 This pull request has now been integrated. Changeset: 6ffa3e66 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/6ffa3e66db55774673ce17be4f8f2d510abf8a84 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported Reviewed-by: minqi, dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From coleenp at openjdk.java.net Thu May 27 00:48:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 27 May 2021 00:48:09 GMT Subject: RFR: 8266891: Provide a switch to force the class space to a specific location In-Reply-To: References: Message-ID: On Tue, 11 May 2021 08:52:55 GMT, Thomas Stuefe wrote: > To test compressed Klass pointer encoding and other metaspace interna, it would be nice to be able to force location of the class space to a specific location. This would help with analysis of problems like JDK-8261552 or JDK-8265705 - errors in Klass* encoding/decoding which managed to stay unnoticed for an astonishingly long time. > > For simplicity, it would be sufficient to only have this ability if CDS is disabled (Xshare=off), since CCS allocation is tied to CDS location otherwise and that would be more diffictult to disentangle. This seems good. Small comment. Were you going to add a test or did you want this to test manually? src/hotspot/share/memory/metaspace.cpp line 716: > 714: // this may fail, in which case the VM will exit after printing an appropiate message. > 715: // Tests using this switch should cope with that. > 716: if (!FLAG_IS_DEFAULT(CompressedClassSpaceBaseAddress) && CompressedClassSpaceBaseAddress != 0) { Don't you just have to test if CompressedClassSpaceBaseAddress != 0 , since that's the default if not set? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3969 From jiefu at openjdk.java.net Thu May 27 01:19:03 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 27 May 2021 01:19:03 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> Message-ID: On Wed, 26 May 2021 15:46:29 GMT, Per Liden wrote: > But then we should remove the check in ZGC, since it serves no purpose anymore when the same check is done in `libnuma_init`. Yes, this is a more general solution. I used to send the RFR in 2020 [1]. But the community didn't pay much attention to it at that time. So we have to get #3704 fixed because ZGC always crashed in docker with numa, while others wouldn't. This week, @tschatzl encouraged me to try JDK-8241423 again. So I sent this PR yesterday hoping that it can be fixed for other gcs too. Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. Thanks. [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-March/041149.html ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From dholmes at openjdk.java.net Thu May 27 02:30:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 02:30:06 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Wed, 26 May 2021 20:31:20 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - inline > - tmp The update seems fine to me. But you need to check with @iklam whether including nonJavaThread.hpp in thread.inline.hpp negates the point of splitting out nonJavaThread.hpp in the first place. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From dcubed at openjdk.java.net Thu May 27 02:31:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 02:31:36 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: > Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable > so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). > Also refactor common hash table size calculation code into static hash_table_size() > function and call it from both places. > > Test with Mach5 Tier[1-7] testing. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4168/files - new: https://git.openjdk.java.net/jdk/pull/4168/files/0e4db022..b57ebc2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4168&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4168&range=01-02 Stats: 41 lines in 2 files changed: 9 ins; 13 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4168/head:pull/4168 PR: https://git.openjdk.java.net/jdk/pull/4168 From darcy at openjdk.java.net Thu May 27 03:25:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 27 May 2021 03:25:41 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v9] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into 8266530 - Fix typo found by @hseigel. - Merge branch 'master' into 8266530 - Respond to review feedback. - Merge branch 'master' into 8266530 - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/96a59d43...0297657a ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/62321229..0297657a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=07-08 Stats: 15901 lines in 1312 files changed: 6589 ins; 6084 del; 3228 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From iklam at openjdk.java.net Thu May 27 04:09:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 27 May 2021 04:09:08 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: <_UQUBgPRgoZ_ODsmuBUJzZw6an_1HRvOn0LUdObTbek=.a031ccc3-1e18-4cdf-af04-e471a2533565@github.com> On Thu, 27 May 2021 02:27:05 GMT, David Holmes wrote: > The update seems fine to me. But you need to check with @iklam whether including nonJavaThread.hpp in thread.inline.hpp negates the point of splitting out nonJavaThread.hpp in the first place. > I think it's OK to include nonJavaThread.hpp in thread.inline.hpp (included by about 30% of hotspot .o files). But we should avoid including it in thread.hpp (included by about 80% of hotspot .o files) BTW, we should make `JavaThread::as_CompilerThread` consistent as well: move to thread.inline.hpp, change the casting, and rename to `as_Compiler_thread` (in another RFE??) ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From iklam at openjdk.java.net Thu May 27 04:09:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 27 May 2021 04:09:07 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Wed, 26 May 2021 20:31:20 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - inline > - tmp Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From dholmes at openjdk.java.net Thu May 27 04:09:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 04:09:08 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Thu, 27 May 2021 02:31:36 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. Updated minimalist approach looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4168 From kbarrett at openjdk.java.net Thu May 27 05:13:06 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 27 May 2021 05:13:06 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Wed, 26 May 2021 20:31:20 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - inline > - tmp Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4167 From dholmes at openjdk.java.net Thu May 27 05:42:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 05:42:05 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4205 From alanb at openjdk.java.net Thu May 27 05:53:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 27 May 2021 05:53:14 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From jiefu at openjdk.java.net Thu May 27 06:04:13 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 27 May 2021 06:04:13 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Thu, 27 May 2021 05:39:39 GMT, David Holmes wrote: > LGTM. > > Thanks, > David Thanks @dholmes-ora . ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From eosterlund at openjdk.java.net Thu May 27 06:07:08 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 27 May 2021 06:07:08 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <8PWWbJYZH49_B_OCRgNPrl085H3wwkM0z_RG63_ewVc=.2e0f74fd-1997-4fa9-82d4-a73b4fcc732a@github.com> On Thu, 27 May 2021 02:31:36 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4168 From rehn at openjdk.java.net Thu May 27 06:37:05 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 27 May 2021 06:37:05 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Thu, 27 May 2021 02:31:36 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From pliden at openjdk.java.net Thu May 27 07:11:04 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 27 May 2021 07:11:04 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> Message-ID: On Thu, 27 May 2021 01:16:32 GMT, Jie Fu wrote: > Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. > And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. I just think the backout of JDK-8241354 and JDK-8266217 should have have been part of this PR. Otherwise this gets harder to review, since the question why we do redundant checks now pops up. But sure, if you prefer backing out JDK-8241354 and JDK-8266217 as a separate change, I'm fine with that too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From jiefu at openjdk.java.net Thu May 27 07:16:05 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 27 May 2021 07:16:05 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> Message-ID: On Thu, 27 May 2021 07:08:28 GMT, Per Liden wrote: > But sure, if you prefer backing out JDK-8241354 and JDK-8266217 as a separate change, I'm fine with that too. Thanks @pliden . I'll file a RFE after this pr. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From ayang at openjdk.java.net Thu May 27 08:13:09 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 27 May 2021 08:13:09 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: <_UQUBgPRgoZ_ODsmuBUJzZw6an_1HRvOn0LUdObTbek=.a031ccc3-1e18-4cdf-af04-e471a2533565@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> <_UQUBgPRgoZ_ODsmuBUJzZw6an_1HRvOn0LUdObTbek=.a031ccc3-1e18-4cdf-af04-e471a2533565@github.com> Message-ID: On Thu, 27 May 2021 04:05:27 GMT, Ioi Lam wrote: > BTW, we should make JavaThread::as_CompilerThread consistent as well: move to thread.inline.hpp, change the casting, and rename to as_Compiler_thread (in another RFE??) I can do so in another PR. Thank you for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From ayang at openjdk.java.net Thu May 27 08:13:10 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 27 May 2021 08:13:10 GMT Subject: RFR: 8252476: as_Worker_thread() doesn't check what it intends [v3] In-Reply-To: References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: <281e9Mbec1P6MYUp2QO48nnokAwDyzW6RS5WiFIl4I4=.8d0a3cb0-7d65-45cb-a657-ca0faebb808e@github.com> On Wed, 26 May 2021 20:31:20 GMT, Albert Mingkun Yang wrote: >> Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - inline > - tmp Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From ayang at openjdk.java.net Thu May 27 08:13:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 27 May 2021 08:13:11 GMT Subject: Integrated: 8252476: as_Worker_thread() doesn't check what it intends In-Reply-To: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> References: <-4q4GwqoaqM7FmCN7Hs9spGSCv774Xp8t4JU9CZ-lb4=.9488d200-18e1-4581-85a8-f5f3f14ef743@github.com> Message-ID: On Mon, 24 May 2021 15:18:00 GMT, Albert Mingkun Yang wrote: > Convert `as_Worker_thread` to non-virtual, like other `as_*_thread` methods. This pull request has now been integrated. Changeset: bfa46f0a Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/bfa46f0af30e9ec073ab5e6411ca94e140113790 Stats: 13 lines in 4 files changed: 7 ins; 5 del; 1 mod 8252476: as_Worker_thread() doesn't check what it intends Co-authored-by: David Holmes Reviewed-by: iklam, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/4167 From mli at openjdk.java.net Thu May 27 08:54:20 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 27 May 2021 08:54:20 GMT Subject: RFR: JDK-8267839: trivial mem leak in numa Message-ID: There is a trivial mem leak in numa related code. This patch is to use a stored bitmask* rather than get a new one. ------------- Commit messages: - numa.leak Changes: https://git.openjdk.java.net/jdk/pull/4219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267839 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4219/head:pull/4219 PR: https://git.openjdk.java.net/jdk/pull/4219 From mdoerr at openjdk.java.net Thu May 27 10:10:15 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 10:10:15 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor Message-ID: We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. ------------- Commit messages: - 8267842: SIGSEGV in get_current_contended_monitor Changes: https://git.openjdk.java.net/jdk/pull/4224/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267842 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From coleenp at openjdk.java.net Thu May 27 12:18:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 27 May 2021 12:18:08 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Thu, 27 May 2021 02:31:36 GMT, Daniel D. Daugherty wrote: >> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable >> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). >> Also refactor common hash table size calculation code into static hash_table_size() >> function and call it from both places. >> >> Test with Mach5 Tier[1-7] testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4168 From vlivanov at openjdk.java.net Thu May 27 12:36:02 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 27 May 2021 12:36:02 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v3] In-Reply-To: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: > Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. > > In particular: > - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; > - pass `TestBuilder` as a parameter and initiate test execution from executor; > - switch max class file version tested from 52 to 61 (`V17`); > - minor changes (cleanups, new test cases) > > Testing: > - [x] vmTestbase/vm/runtime/defmeth/ > - [x] hs-tier5-rt - hs-tier8-rt Vladimir Ivanov has updated the pull request incrementally with two additional commits since the last revision: - Remove references to JVMS-8 and the drafts - Copyright year update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4008/files - new: https://git.openjdk.java.net/jdk/pull/4008/files/9406cdc1..bcba4283 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=01-02 Stats: 12 lines in 8 files changed: 0 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4008/head:pull/4008 PR: https://git.openjdk.java.net/jdk/pull/4008 From vlivanov at openjdk.java.net Thu May 27 12:36:11 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 27 May 2021 12:36:11 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Tue, 25 May 2021 22:06:45 GMT, Vladimir Ivanov wrote: >> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. >> >> In particular: >> - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; >> - pass `TestBuilder` as a parameter and initiate test execution from executor; >> - switch max class file version tested from 52 to 61 (`V17`); >> - minor changes (cleanups, new test cases) >> >> Testing: >> - [x] vmTestbase/vm/runtime/defmeth/ >> - [x] hs-tier5-rt - hs-tier8-rt > > 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 seven additional commits since the last revision: > > - Merge branch 'master' into 8267095.defmeth > - Remove ACC_STRICT-related code > - Cleanup > - Remove scenarios > - FIXME removal > - Fixes > - TestBuilder as a parameter Thanks for the review, David. > One thing we seem to have lost is the documentation for what this setup code: > actually means. Do you think additional comments can improve the situation? > Also references to JVMS8 should probably just say JVMS. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4008 From vlivanov at openjdk.java.net Thu May 27 12:36:15 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 27 May 2021 12:36:15 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Wed, 26 May 2021 13:13:57 GMT, Harold Seigel 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into 8267095.defmeth >> - Remove ACC_STRICT-related code >> - Cleanup >> - Remove scenarios >> - FIXME removal >> - Fixes >> - TestBuilder as a parameter > > test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java line 163: > >> 161: majorVerValues[i] = MIN_MAJOR_VER + i; >> 162: } >> 163: > > Does this mean that the stress tests will run for all class versions between JDK 1.5 and JDK 17 ? If so, maybe change it to just run for JDK 1.5, 11, and 17 releases? It means that the stress test will randomly pick test cases with class file versions between `MIN_MAJOR_VER` and `MAX_MAJOR_VER`. IMO it's a decent compromise between testing only `MIN_MAJOR_VER` and `MAX_MAJOR_VER` (all other defmeth tests are configured that way) and always enumerating all the class file versions in every test (`MIN_MAJOR_VER ... MAX_MAJOR_VER`). So, I'd prefer to keep it as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/4008 From hseigel at openjdk.java.net Thu May 27 12:46:08 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 27 May 2021 12:46:08 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On Thu, 27 May 2021 12:30:29 GMT, Vladimir Ivanov wrote: >> test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/StressTest.java line 163: >> >>> 161: majorVerValues[i] = MIN_MAJOR_VER + i; >>> 162: } >>> 163: >> >> Does this mean that the stress tests will run for all class versions between JDK 1.5 and JDK 17 ? If so, maybe change it to just run for JDK 1.5, 11, and 17 releases? > > It means that the stress test will randomly pick test cases with class file versions between `MIN_MAJOR_VER` and `MAX_MAJOR_VER`. IMO it's a decent compromise between testing only `MIN_MAJOR_VER` and `MAX_MAJOR_VER` (all other defmeth tests are configured that way) and always enumerating all the class file versions in every test (`MIN_MAJOR_VER ... MAX_MAJOR_VER`). So, I'd prefer to keep it as is. That sounds good. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4008 From lzang at openjdk.java.net Thu May 27 14:00:03 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 27 May 2021 14:00:03 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> On Wed, 26 May 2021 09:34:06 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance. > > I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump. > > Thanks! Hi @AntonKozlov, I am not a reviewer, just a tiny hint that you may need to add test cases. Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From lzang at openjdk.java.net Thu May 27 14:04:07 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 27 May 2021 14:04:07 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: <_Q4Udr3OeDaLPcDEuGfcUXCW1WNx_tCQCO3u3iMWPIU=.0cd90173-a8b5-43ef-b11f-6a6cc1d52517@github.com> On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Moreover, it seems the /csr label is required ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From simonis at openjdk.java.net Thu May 27 14:33:08 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 27 May 2021 14:33:08 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Hi Martin, your fix looks good but I'm a little concerned because there are other call sites which us a similar pattern. E.g. in `jvmtiEnvBase.cpp`: vmtiEnvBase::get_current_contended_monitor(JavaThread *calling_thread, JavaThread *java_thread, jobject *monitor_ptr) { Thread *current_thread = Thread::current(); assert(java_thread->is_handshake_safe_for(current_thread), "call by myself or at handshake"); oop obj = NULL; // The ObjectMonitor* can't be async deflated since we are either // at a safepoint or the calling thread is operating on itself so // it cannot leave the underlying wait()/enter() call. ObjectMonitor *mon = java_thread->current_waiting_monitor(); if (mon == NULL) { // thread is not doing an Object.wait() call mon = java_thread->current_pending_monitor(); if (mon != NULL) { // The thread is trying to enter() an ObjectMonitor. obj = mon->object(); assert(obj != NULL, "ObjectMonitor should have a valid object!"); } // implied else: no contended ObjectMonitor } else { // thread is doing an Object.wait() call obj = mon->object(); assert(obj != NULL, "Object.wait() should have an object"); } So I wonder if we shouldn't make `current_waiting_monitor()`/`current_pending_monitor()` return volatile pointers to make it clear to the callers that these pointers can change at any time? I'm also not that deep into `ThreadService` & al. to understand what happens after your fix. Now you don't reload the waiting monitor but you might use it although it has already been cleared out from the thread (in the case where you previously crashed). Is that still OK? ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Thu May 27 15:01:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 15:01:17 GMT Subject: Integrated: 8191786: Thread-SMR hash table size should be dynamic In-Reply-To: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: On Mon, 24 May 2021 16:06:23 GMT, Daniel D. Daugherty wrote: > Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable > so that a variable sized hash table is used instead of a fixed size hash table (1031 elements). > Also refactor common hash table size calculation code into static hash_table_size() > function and call it from both places. > > Test with Mach5 Tier[1-7] testing. This pull request has now been integrated. Changeset: 23189a1f Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/23189a1f9de5e7c039a4f6b9e5eefe4fa3c6dcef Stats: 16 lines in 1 file changed: 0 ins; 11 del; 5 mod 8191786: Thread-SMR hash table size should be dynamic Reviewed-by: dholmes, rehn, coleenp, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From dcubed at openjdk.java.net Thu May 27 15:01:16 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 15:01:16 GMT Subject: RFR: 8191786: Thread-SMR hash table size should be dynamic [v3] In-Reply-To: References: <2qRilxmqekgW6eVIo_HjcSPaeLr54z3YSDgQv-ruKb8=.e901e070-604f-4e82-be68-8275a05e013e@github.com> Message-ID: <8puB07zld_W_4FMNUuveCX3KMeY5CNNraQtpnxERbjQ=.fac7e468-d220-4ab3-9646-68cc55f8bad8@github.com> On Thu, 27 May 2021 04:06:07 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Rewind and remove the unused hash_table_size calculations; ThreadScanHashtable is now fixed size. > > Updated minimalist approach looks good. > > Thanks, > David @dholmes-ora, @fisk, @robehn and @coleenp - Thanks for the re-reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4168 From stefank at openjdk.java.net Thu May 27 15:23:06 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 27 May 2021 15:23:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From smarks at openjdk.java.net Thu May 27 15:23:10 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 27 May 2021 15:23:10 GMT Subject: Integrated: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) This pull request has now been integrated. Changeset: 7c85f351 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/7c85f3510cb84881ff232548fbcc933ef4b34972 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod 8267123: Remove RMI Activation Reviewed-by: erikj, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From dcubed at openjdk.java.net Thu May 27 15:34:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 15:34:10 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: <10QrcaFzCe0ljID0VdjMX_gCeSkay_Mjkn28e52swN8=.7ecf20ee-f4c9-4a68-be22-e38118798439@github.com> References: <10QrcaFzCe0ljID0VdjMX_gCeSkay_Mjkn28e52swN8=.7ecf20ee-f4c9-4a68-be22-e38118798439@github.com> Message-ID: On Thu, 27 May 2021 15:29:13 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Hi Volker, > thanks for looking at my proposal. > > I had seen the JVMTIEnvBase version of it. The comment says: > ` // The ObjectMonitor* can't be async deflated since we are either > // at a safepoint or the calling thread is operating on itself so > // it cannot leave the underlying wait()/enter() call.` > > The ThreadService version's comment says: > ` // This function can be called on a target JavaThread that is not // the caller and we are not at a safepoint. So it is possible for // the waiting or pending condition to be over/stale and for the // first stage of async deflation to clear the object field in // the ObjectMonitor. It is also possible for the object to be // inflated again and to be associated with a completely different // ObjectMonitor by the time this object reference is processed // by the caller.` > > So the affected code is a special usage. I don't know if a more generic fix would be desirable. > Accessing the ObjectMonitor after it was removed from the thread seems to be intended according to this comment. To verify that it's safe, one would have to check the protocol which is described here: https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation > (not a trivial task!) @TheRealMDoerr - You should also add the Serviceability group for this reivew. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 15:34:09 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 15:34:09 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: <10QrcaFzCe0ljID0VdjMX_gCeSkay_Mjkn28e52swN8=.7ecf20ee-f4c9-4a68-be22-e38118798439@github.com> On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Hi Volker, thanks for looking at my proposal. I had seen the JVMTIEnvBase version of it. The comment says: ` // The ObjectMonitor* can't be async deflated since we are either // at a safepoint or the calling thread is operating on itself so // it cannot leave the underlying wait()/enter() call.` The ThreadService version's comment says: ` // This function can be called on a target JavaThread that is not // the caller and we are not at a safepoint. So it is possible for // the waiting or pending condition to be over/stale and for the // first stage of async deflation to clear the object field in // the ObjectMonitor. It is also possible for the object to be // inflated again and to be associated with a completely different // ObjectMonitor by the time this object reference is processed // by the caller.` So the affected code is a special usage. I don't know if a more generic fix would be desirable. Accessing the ObjectMonitor after it was removed from the thread seems to be intended according to this comment. To verify that it's safe, one would have to check the protocol which is described here: https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation (not a trivial task!) ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 15:53:05 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 15:53:05 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson wrote: > I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192. Hi Stefan, thanks for looking at it and thanks for the pointer. I do remember that Atomic::load should be preferred. But I would have to use it in thread.hpp and I don't know if I should change it in current_waiting_monitor() and current_pending_monitor(). Would it be acceptable to change the general code for this special usage? I'm not against doing it, I just want to double-check. It may improve reliability in general. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Thu May 27 16:47:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 16:47:07 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Thumbs up. The code that you're fixing is indeed a special case and I wrote the new test (serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java) specifically to stress the crashing code path. Unfortunately, I have never seen the new test fail in our test in Mach5 or in my testing in my lab. We did get a single closed test failure back on 2021.03.20 which is what started me down the path of creating the new test. That single failure has never reproduced in the original closed test nor in the targeted test that I wrote (GetLockOwnerName.java). The similar usage in JVM/TI is safe for exactly the reasons explained in the comment so a general Atomic::load() solution in current_waiting_monitor() or current_pending_monitor() is not necessary. I think your solution of adding `volatile` to `wait_obj` and `enter_obj` is a good solution. I would like to see a comment added to explain the need for the `volatile`. I'll add an embedded comment in the other PR view. Using either `wait_obj` or `enter_obj` after it has been cleared from the JavaThread is safe. The ObjectMonitor can only have gone through the first stage of async deflation. The ObjectMonitor's memory cannot be freed until after a handshake with all threads is completed and that cannot happen while this thread is executing the code that is using `wait_obj` or `enter_obj`. src/hotspot/share/services/threadService.cpp line 232: > 230: // ObjectMonitor by the time this object reference is processed > 231: // by the caller. > 232: ObjectMonitor* volatile wait_obj = thread->current_waiting_monitor(); Please add a comment above this declaration. Something like: // Using 'volatile' to prevent the compiler from generating code that // reloads 'wait_obj' from memory when used below. src/hotspot/share/services/threadService.cpp line 239: > 237: obj = wait_obj->object(); > 238: } else { > 239: ObjectMonitor* volatile enter_obj = thread->current_pending_monitor(); Please add a comment above this declaration. Something like: // Using 'volatile' to prevent the compiler from generating code that // reloads 'enter_obj' from memory when used below. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 16:56:25 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 16:56:25 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Add comments as suggested by Dan. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/6e444fab..97a7df60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 17:01:12 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 17:01:12 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments as suggested by Dan. Thanks for the review! Comment added. We have only seen the crash on s390. It depends on the platform if the compiler tends to reload values more or less. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From david.holmes at oracle.com Thu May 27 23:20:12 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 May 2021 09:20:12 +1000 Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: On 27/05/2021 10:36 pm, Vladimir Ivanov wrote: > On Tue, 25 May 2021 22:06:45 GMT, Vladimir Ivanov wrote: > >>> Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. >>> >>> In particular: >>> - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; >>> - pass `TestBuilder` as a parameter and initiate test execution from executor; >>> - switch max class file version tested from 52 to 61 (`V17`); >>> - minor changes (cleanups, new test cases) >>> >>> Testing: >>> - [x] vmTestbase/vm/runtime/defmeth/ >>> - [x] hs-tier5-rt - hs-tier8-rt >> >> 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into 8267095.defmeth >> - Remove ACC_STRICT-related code >> - Cleanup >> - Remove scenarios >> - FIXME removal >> - Fixes >> - TestBuilder as a parameter > > Thanks for the review, David. > >> One thing we seem to have lost is the documentation for what this setup code: >> actually means. > > Do you think additional comments can improve the situation? I was thinking more of restoring something to the readme. >> Also references to JVMS8 should probably just say JVMS. > > Fixed. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4008 > From jiefu at openjdk.java.net Fri May 28 02:15:05 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 28 May 2021 02:15:05 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() May I get a second review for this change? Or is it already OK to be pushed? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From dholmes at openjdk.java.net Fri May 28 02:42:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 02:42:05 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() Two reviews needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From dholmes at openjdk.java.net Fri May 28 06:49:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 06:49:04 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments as suggested by Dan. Hi Martin, I'm with @stefank. This special case is a race condition and the solution for that is Atomic::load/store. Given Atomic::load/store don't actually need to do anything in practice (other than act as marker of a race) I don't have any qualms about using them all the time. Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From ysuenaga at openjdk.java.net Fri May 28 07:10:06 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 07:10:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comments as suggested by Dan. > > I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192. I agree with @stefank and @dholmes-ora . It is nature to happen the change in thread.hpp to fix this problem. > Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue. Now we have Thread-Local handshake. I think we should use it at here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From rehn at openjdk.java.net Fri May 28 07:30:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 28 May 2021 07:30:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 14:45:07 GMT, Daniel D. Daugherty wrote: > Thumbs up. > > Reviewed the incremental between v05 -> v06. Looks good. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Fri May 28 07:34:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 28 May 2021 07:34:15 GMT Subject: Integrated: 8265753: Remove manual JavaThread transitions to blocked In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:11:04 GMT, Robbin Ehn wrote: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. This pull request has now been integrated. Changeset: 97ec5ad0 Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/97ec5ad0a6ed2cd87a9c75b0559e9bb55b72121e Stats: 340 lines in 8 files changed: 119 ins; 150 del; 71 mod 8265753: Remove manual JavaThread transitions to blocked Reviewed-by: dcubed, rrich, dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Fri May 28 07:45:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 28 May 2021 07:45:33 GMT Subject: RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be [v3] In-Reply-To: References: Message-ID: <3m9fT7cUyrFRgwfTGc65DJBmwunAEHAHp02_FO8UK90=.84d37913-e9bf-4518-afb0-efdc0fbd00ed@github.com> > Please consider this change-set which address the issue on hand. > > I identified two problems: > > - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side. > Fixed by leaving the handshakee being processed in queue until completed. > And remove looping, since if ever the queue is empty the handshakee may processed. > If ever want to loop again, we must make sure queue is not empty before removing the processed handshake. > But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference) > > Note that I'll do a follow-up and make is_locked() ifdef ASSERT only. > > - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state. > Fixed by adding a loadload. > > I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten. > (real reprod ~1/400 with increased test time) > If we are updating the poll there should not be an active handshaker. > The above fixed the issue. > But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes. > > Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker). > > Passes stressing relevant test on aarch64 and t1-7. > > Thanks, Robbin Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into handshakee - Small update - Merge branch 'master' into handshakee - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3973/files - new: https://git.openjdk.java.net/jdk/pull/3973/files/03bbb423..d5028125 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3973&range=01-02 Stats: 37179 lines in 1546 files changed: 7523 ins; 26507 del; 3149 mod Patch: https://git.openjdk.java.net/jdk/pull/3973.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3973/head:pull/3973 PR: https://git.openjdk.java.net/jdk/pull/3973 From iignatyev at openjdk.java.net Fri May 28 07:53:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 28 May 2021 07:53:08 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 09:38:30 GMT, Jie Fu wrote: >> I think a better solution would be to split the test into two subtests (two separate jtreg test descriptions in one .java file): one for `doTest` another for `doTestCustomLoader` and use `@requires vm.cds.custom.loaders` in the 2nd one. this way, we will get more clear test results. >> >> Cheers, >> -- Igor > >> I think a better solution would be to split the test into two subtests (two separate jtreg test descriptions in one .java file): one for `doTest` another for `doTestCustomLoader` and use `@requires vm.cds.custom.loaders` in the 2nd one. this way, we will get more clear test results. >> >> Cheers, >> -- Igor > > > Thanks @iignatev for your review and sharing. > I didn't know this skill before. > > Splitting the test into two subtests seems making a tiny bit sense since the CI/CD won't care which sub-tests are not run. > > I prefer the current (minimal) change since I think it's already good enough and I didn't find an easy way to rewrite it. > > Thanks. well, smth like[1] should do the trick (haven't tested) and isn't that big of the change. -- Igor [1] ```diff --git a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java index 9c6d53e7092..5acfc69479a 100644 --- a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java +++ b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java @@ -22,10 +22,10 @@ */ /** - * @test + * @test id=default-cl * @requires vm.cds * @summary Test class loader constraint checks for archived classes - * @bug 8267347 8267754 + * @bug 8267754 * @library /test/lib * /test/hotspot/jtreg/runtime/cds/appcds * /test/hotspot/jtreg/runtime/cds/appcds/test-classes @@ -34,6 +34,20 @@ * @run driver LoaderConstraintsTest */ +/** + * @test id=custom-cl + * @requires vm.cds.custom.loaders + * @summary Test class loader constraint checks for archived classes with custom class loader + * @bug 8267347 8267754 + * @library /test/lib + * /test/hotspot/jtreg/runtime/cds/appcds + * /test/hotspot/jtreg/runtime/cds/appcds/test-classes + * @modules java.base/jdk.internal.misc + * jdk.httpserver + * @run driver LoaderConstraintsTest custom + */ + + import com.sun.net.httpserver.HttpExchange; import com.sun.net.httpserver.HttpHandler; import jdk.test.lib.Asserts; @@ -109,8 +123,9 @@ public class LoaderConstraintsTest { public static void main(String... args) throws Exception { appJar = ClassFileInstaller.writeJar("loader_constraints.jar", appClasses); - doTest(); - if (Platform.areCustomLoadersSupportedForCDS()) { + if (args.length == 0) { + doTest(); + } else { loaderJar = ClassFileInstaller.writeJar("custom_app_loader.jar", loaderClasses); doTestCustomLoader(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From jiefu at openjdk.java.net Fri May 28 08:28:09 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 28 May 2021 08:28:09 GMT Subject: RFR: 8267754: cds/appcds/loaderConstraints/LoaderConstraintsTest.java fails on x86_32 due to customized class loader is not supported [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 07:49:36 GMT, Igor Ignatyev wrote: >>> I think a better solution would be to split the test into two subtests (two separate jtreg test descriptions in one .java file): one for `doTest` another for `doTestCustomLoader` and use `@requires vm.cds.custom.loaders` in the 2nd one. this way, we will get more clear test results. >>> >>> Cheers, >>> -- Igor >> >> >> Thanks @iignatev for your review and sharing. >> I didn't know this skill before. >> >> Splitting the test into two subtests seems making a tiny bit sense since the CI/CD won't care which sub-tests are not run. >> >> I prefer the current (minimal) change since I think it's already good enough and I didn't find an easy way to rewrite it. >> >> Thanks. > > well, smth like[1] should do the trick (haven't tested) and isn't that big of the change. > > -- Igor > > [1] > ```diff --git a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java > index 9c6d53e7092..5acfc69479a 100644 > --- a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java > +++ b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java > @@ -22,10 +22,10 @@ > */ > > /** > - * @test > + * @test id=default-cl > * @requires vm.cds > * @summary Test class loader constraint checks for archived classes > - * @bug 8267347 8267754 > + * @bug 8267754 > * @library /test/lib > * /test/hotspot/jtreg/runtime/cds/appcds > * /test/hotspot/jtreg/runtime/cds/appcds/test-classes > @@ -34,6 +34,20 @@ > * @run driver LoaderConstraintsTest > */ > > +/** > + * @test id=custom-cl > + * @requires vm.cds.custom.loaders > + * @summary Test class loader constraint checks for archived classes with custom class loader > + * @bug 8267347 8267754 > + * @library /test/lib > + * /test/hotspot/jtreg/runtime/cds/appcds > + * /test/hotspot/jtreg/runtime/cds/appcds/test-classes > + * @modules java.base/jdk.internal.misc > + * jdk.httpserver > + * @run driver LoaderConstraintsTest custom > + */ > + > + > import com.sun.net.httpserver.HttpExchange; > import com.sun.net.httpserver.HttpHandler; > import jdk.test.lib.Asserts; > @@ -109,8 +123,9 @@ public class LoaderConstraintsTest { > > public static void main(String... args) throws Exception { > appJar = ClassFileInstaller.writeJar("loader_constraints.jar", appClasses); > - doTest(); > - if (Platform.areCustomLoadersSupportedForCDS()) { > + if (args.length == 0) { > + doTest(); > + } else { > loaderJar = ClassFileInstaller.writeJar("custom_app_loader.jar", loaderClasses); > doTestCustomLoader(); > } > well, smth like[1] should do the trick (haven't tested) and isn't that big of the change. > > -- Igor > > [1] > > ```diff > index 9c6d53e7092..5acfc69479a 100644 > --- a/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java > +++ b/test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java > @@ -22,10 +22,10 @@ > */ > > /** > - * @test > + * @test id=default-cl > * @requires vm.cds > * @summary Test class loader constraint checks for archived classes > - * @bug 8267347 8267754 > + * @bug 8267754 > * @library /test/lib > * /test/hotspot/jtreg/runtime/cds/appcds > * /test/hotspot/jtreg/runtime/cds/appcds/test-classes > @@ -34,6 +34,20 @@ > * @run driver LoaderConstraintsTest > */ > > +/** > + * @test id=custom-cl > + * @requires vm.cds.custom.loaders > + * @summary Test class loader constraint checks for archived classes with custom class loader > + * @bug 8267347 8267754 > + * @library /test/lib > + * /test/hotspot/jtreg/runtime/cds/appcds > + * /test/hotspot/jtreg/runtime/cds/appcds/test-classes > + * @modules java.base/jdk.internal.misc > + * jdk.httpserver > + * @run driver LoaderConstraintsTest custom > + */ > + > + > import com.sun.net.httpserver.HttpExchange; > import com.sun.net.httpserver.HttpHandler; > import jdk.test.lib.Asserts; > @@ -109,8 +123,9 @@ public class LoaderConstraintsTest { > > public static void main(String... args) throws Exception { > appJar = ClassFileInstaller.writeJar("loader_constraints.jar", appClasses); > - doTest(); > - if (Platform.areCustomLoadersSupportedForCDS()) { > + if (args.length == 0) { > + doTest(); > + } else { > loaderJar = ClassFileInstaller.writeJar("custom_app_loader.jar", loaderClasses); > doTestCustomLoader(); > } > ``` Good. The patch is much better than what I had thought it might be. But it's still bigger than the integrated one. I've learned your skill and will use it next time if necessary. Thank you so much, @iignatev . ------------- PR: https://git.openjdk.java.net/jdk/pull/4198 From iignatyev at openjdk.java.net Fri May 28 08:37:19 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 28 May 2021 08:37:19 GMT Subject: RFR: 8267917: mark hotspot containers tests which ignore external VM flags Message-ID: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com> Hi all, could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags? attn: @mseledts Cheers, -- Igor ------------- Commit messages: - 8267917 Changes: https://git.openjdk.java.net/jdk/pull/4241/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4241&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267917 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4241.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4241/head:pull/4241 PR: https://git.openjdk.java.net/jdk/pull/4241 From iwalulya at openjdk.java.net Fri May 28 09:18:06 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Fri, 28 May 2021 09:18:06 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:08:50 GMT, Stefan Johansson wrote: > Please review this change to fix the large page testing on Windows. > > **Summary** > The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). > > When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. > > The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. > > **Testing** > Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. lgtm! ------------- Marked as reviewed by iwalulya (Committer). PR: https://git.openjdk.java.net/jdk/pull/4090 From jiefu at openjdk.java.net Fri May 28 09:47:03 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 28 May 2021 09:47:03 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> Message-ID: On Thu, 27 May 2021 07:08:28 GMT, Per Liden wrote: >>> But then we should remove the check in ZGC, since it serves no purpose anymore when the same check is done in `libnuma_init`. >> >> Yes, this is a more general solution. >> >> I used to send the RFR in 2020 [1]. >> But the community didn't pay much attention to it at that time. >> So we have to get #3704 fixed because ZGC always crashed in docker with numa, while others wouldn't. >> >> This week, @tschatzl encouraged me to try JDK-8241423 again. >> So I sent this PR yesterday hoping that it can be fixed for other gcs too. >> >> Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. >> And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. >> Thanks. >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-March/041149.html > >> Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. >> And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. > > I just think the backout of JDK-8241354 and JDK-8266217 should have have been part of this PR. Otherwise this gets harder to review, since the question why we do redundant checks now pops up. But sure, if you prefer backing out JDK-8241354 and JDK-8266217 as a separate change, I'm fine with that too. Hi @pliden and @tschatzl , Could you please review this change? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From mdoerr at openjdk.java.net Fri May 28 10:13:25 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 10:13:25 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/97a7df60..f4005ec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01-02 Stats: 14 lines in 2 files changed: 3 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 10:19:04 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 10:19:04 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. Thanks, folks, for reviewing! Changed to use Atomic::load/store. With this version, we use volatile accesses to these two members consistently. This may restrict compiler optimizations a bit, but I wouldn't expect a performance problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Fri May 28 10:49:32 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 10:49:32 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Extend HeapDumpTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4183/files - new: https://git.openjdk.java.net/jdk/pull/4183/files/c3b4bc58..7faa6900 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=00-01 Stats: 12 lines in 2 files changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183 PR: https://git.openjdk.java.net/jdk/pull/4183 From akozlov at openjdk.java.net Fri May 28 11:01:05 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 11:01:05 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> References: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> Message-ID: On Thu, 27 May 2021 13:57:05 GMT, Lin Zang wrote: > you may need to add test cases A test is trivial. Just in case, I've added it. > it seems the /csr label is required Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From pliden at openjdk.java.net Fri May 28 11:18:04 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 28 May 2021 11:18:04 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> Message-ID: On Wed, 26 May 2021 14:28:39 GMT, Jie Fu wrote: >> Hi all, >> >> NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. >> >> NUMA APIs depend on several syscalls. >> E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. >> But these dependent syscalls can be unsupported for various reasons. >> Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. >> So it's necessary to check whether the syscalls are available. >> >> In theory, all NUMA-related syscalls should be checked. >> But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. >> So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. >> And this can be refined in the future if it turns out to be a problem. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://docs.docker.com/engine/security/seccomp/ > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove os::Linux namespace for numa_syscall_check() Marked as reviewed by pliden (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From lzang at openjdk.java.net Fri May 28 11:53:08 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 28 May 2021 11:53:08 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Hi Anton, > Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway. AFAIK, the `csr` label will be removed by the `bot` when it gets approved. I usually add it in PR when CSR is required, and maybe it could help reviewer notice it and hence review the CSR. Also it could help guarantee the PR not to be pushed when CSR is not approved. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From sjohanss at openjdk.java.net Fri May 28 12:28:22 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 28 May 2021 12:28:22 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages [v2] In-Reply-To: References: Message-ID: > Please review this change to fix the large page testing on Windows. > > **Summary** > The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). > > When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. > > The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. > > **Testing** > Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Albert review, updated failure message. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4090/files - new: https://git.openjdk.java.net/jdk/pull/4090/files/bc86a6fa..e8803de1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4090&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4090&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4090/head:pull/4090 PR: https://git.openjdk.java.net/jdk/pull/4090 From sjohanss at openjdk.java.net Fri May 28 12:46:29 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 28 May 2021 12:46:29 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages [v3] In-Reply-To: References: Message-ID: > Please review this change to fix the large page testing on Windows. > > **Summary** > The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). > > When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. > > The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. > > **Testing** > Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Albert review. Harden test to not allow failure for request address ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4090/files - new: https://git.openjdk.java.net/jdk/pull/4090/files/e8803de1..c92f81b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4090&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4090&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4090.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4090/head:pull/4090 PR: https://git.openjdk.java.net/jdk/pull/4090 From ysuenaga at openjdk.java.net Fri May 28 12:54:05 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 12:54:05 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From ayang at openjdk.java.net Fri May 28 12:56:08 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 28 May 2021 12:56:08 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:46:29 GMT, Stefan Johansson wrote: >> Please review this change to fix the large page testing on Windows. >> >> **Summary** >> The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). >> >> When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. >> >> The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. >> >> **Testing** >> Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Albert review. Harden test to not allow failure for request address Preexisting: there are two early returns (`!UseLargePages` and `result == NULL`), which could make the test pass without testing anything. I think this is problematic and should be addressed. ------------- Marked as reviewed by ayang (Committer). PR: https://git.openjdk.java.net/jdk/pull/4090 From ysuenaga at openjdk.java.net Fri May 28 12:59:07 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 12:59:07 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest I think `-f` (force) is more suitable like `cp` on Linux - Maybe it should be discussed on CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From mdoerr at openjdk.java.net Fri May 28 13:15:29 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:15:29 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v4] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Make the 2 member fields volatile. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/f4005ec0..932a7dfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:25:23 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:25:23 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: whitespace fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/932a7dfd..c3e58884 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:25:24 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:25:24 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:51:26 GMT, Yasumasa Suenaga wrote: > Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`? Right. Done. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:30:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:30:14 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: <-N7ZeEqwfU4zlySMnBX3O8uBc01N9uWgqxRotI_Y7EQ=.e9cd29e9-6e78-4829-a1c6-6b2bea341280@github.com> On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > whitespace fix Thumbs up. Just a couple of suggestions about the comments. src/hotspot/share/runtime/thread.hpp line 757: > 755: ObjectMonitor* current_pending_monitor() { > 756: // Using atomic load to prevent compilers from reloading (ThreadService::get_current_contended_monitor). > 757: // In case of concurrent modification, reloading pointer after NULL check must be prevented. Perhaps rewrite the comment like this: // Use Atomic::load() to prevent data race between concurrent modification and // concurrent readers, e.g., ThreadService::get_current_contended_monitor(). src/hotspot/share/runtime/thread.hpp line 770: > 768: } > 769: ObjectMonitor* current_waiting_monitor() { > 770: // Using atomic load as in current_pending_monitor. Perhaps: `// See the comment in current_pending_monitor() above.` ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:42:30 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:42:30 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Improve comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/c3e58884..49354d0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:42:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:42:30 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 07:06:50 GMT, Yasumasa Suenaga wrote: > I thought we took snapshots when threads were known to be safe and stable. When we ask for snapshots with stack traces, we use a safepoint to get all of target thread's stack traces at the same time. Obviously that code path is safe. The "other" code path is when we don't ask for stack traces and that path has always been carefully coded to return non stack trace information in a safe manner, but it does not use a safepoint or a handshake. This duality in code paths is why the new test I wrote: serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java makes alternating calls of asking for the stack trace and then not. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:42:31 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:42:31 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > whitespace fix Thanks for the review! I have improved the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:50:15 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:50:15 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From jiefu at openjdk.java.net Fri May 28 13:55:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 28 May 2021 13:55:11 GMT Subject: RFR: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default [v2] In-Reply-To: References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> <1C60q0KlgHhcHPWK9fUjoP_h_NP2JbRA0NTT7HNIuA0=.5bba5364-480b-4f68-a2ab-33dd97bb2d0c@github.com> <2okyryniOO79iaViF0snKglEGCUCmA0gl-mVADbMzxM=.7d806180-74cd-4da8-8293-3d72d684f97f@github.com> Message-ID: On Thu, 27 May 2021 07:08:28 GMT, Per Liden wrote: >>> But then we should remove the check in ZGC, since it serves no purpose anymore when the same check is done in `libnuma_init`. >> >> Yes, this is a more general solution. >> >> I used to send the RFR in 2020 [1]. >> But the community didn't pay much attention to it at that time. >> So we have to get #3704 fixed because ZGC always crashed in docker with numa, while others wouldn't. >> >> This week, @tschatzl encouraged me to try JDK-8241423 again. >> So I sent this PR yesterday hoping that it can be fixed for other gcs too. >> >> Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. >> And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. >> Thanks. >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-March/041149.html > >> Changes in ZGC (JDK-8241354 and JDK-8266217) would become unnecessary if this PR is accepted. >> And to make it to be more friendly to get reviewed, it would be better to file another RFE to remove them in ZGC. > > I just think the backout of JDK-8241354 and JDK-8266217 should have have been part of this PR. Otherwise this gets harder to review, since the question why we do redundant checks now pops up. But sure, if you prefer backing out JDK-8241354 and JDK-8266217 as a separate change, I'm fine with that too. Thanks @pliden . ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From jiefu at openjdk.java.net Fri May 28 13:55:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 28 May 2021 13:55:11 GMT Subject: Integrated: 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default In-Reply-To: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> References: <1qerQuUf-tqrtonWJR6xRW2Z_ZP5hsmPmz1CQufMJtA=.8eb4ad2d-3006-4a13-bb9b-c9ef435ff889@github.com> Message-ID: On Wed, 26 May 2021 12:49:34 GMT, Jie Fu wrote: > Hi all, > > NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default. > > NUMA APIs depend on several syscalls. > E.g., `get_mempolicy` is required for `numa_get_membind` and `numa_get_interleave_mask`. > But these dependent syscalls can be unsupported for various reasons. > Especially in dockers, `get_mempolicy` is not allowed with the default configuration [1]. > So it's necessary to check whether the syscalls are available. > > In theory, all NUMA-related syscalls should be checked. > But it seems hard to do so because some of them like `mbind` would cause unexpected side effects. > So only `get_mempolicy` is checked in the fix, which is already enough for all the default dockers. > And this can be refined in the future if it turns out to be a problem. > > Thanks. > Best regards, > Jie > > [1] https://docs.docker.com/engine/security/seccomp/ This pull request has now been integrated. Changeset: 1413f9e0 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/1413f9e070b19bed33a4552f3e7adb53cf7daf73 Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod 8241423: NUMA APIs fail to work in dockers due to dependent syscalls are disabled by default Reviewed-by: dholmes, pliden ------------- PR: https://git.openjdk.java.net/jdk/pull/4205 From stefank at openjdk.java.net Fri May 28 14:04:06 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 28 May 2021 14:04:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Looks good. Thanks! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 14:57:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 14:57:13 GMT Subject: RFR: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls Message-ID: A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. See the bug report for the details. Tested with Mach5 Tier1. ------------- Commit messages: - 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls Changes: https://git.openjdk.java.net/jdk/pull/4236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264624 Stats: 17 lines in 2 files changed: 4 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4236/head:pull/4236 PR: https://git.openjdk.java.net/jdk/pull/4236 From ysuenaga at openjdk.java.net Fri May 28 16:04:06 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 16:04:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Marked as reviewed by ysuenaga (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Fri May 28 16:07:12 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 16:07:12 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: <5t-TViZqHB79VDJSiOs4pY2wiYiIvwm35G5G7us7Rl8=.9ef26c20-d5fc-4a6b-b527-52d7db59cee6@github.com> On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest `-f` is overloaded with meanings in various Unix utilities, I'd like to keep it specific. For example, `cp -f` will actually do something different, it will delete the file and create a new one. `jcmd -rewrite` will reuse the same file. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From pchilanomate at openjdk.java.net Fri May 28 16:08:08 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 28 May 2021 16:08:08 GMT Subject: RFR: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls In-Reply-To: References: Message-ID: On Fri, 28 May 2021 00:00:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. > See the bug report for the details. > > Tested with Mach5 Tier1. LGTM. ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/4236 From coleenp at openjdk.java.net Fri May 28 16:08:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 28 May 2021 16:08:08 GMT Subject: RFR: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls In-Reply-To: References: Message-ID: On Fri, 28 May 2021 00:00:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. > See the bug report for the details. > > Tested with Mach5 Tier1. +1 and trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4236 From dcubed at openjdk.java.net Fri May 28 16:08:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 16:08:08 GMT Subject: RFR: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls In-Reply-To: References: Message-ID: On Fri, 28 May 2021 16:03:22 GMT, Patricio Chilano Mateo wrote: >> A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. >> See the bug report for the details. >> >> Tested with Mach5 Tier1. > > LGTM. @pchilano - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4236 From dcubed at openjdk.java.net Fri May 28 16:27:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 16:27:13 GMT Subject: RFR: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls In-Reply-To: References: Message-ID: On Fri, 28 May 2021 16:04:59 GMT, Coleen Phillimore wrote: >> A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. >> See the bug report for the details. >> >> Tested with Mach5 Tier1. > > +1 and trivial. @coleenp - Thanks for the review ------------- PR: https://git.openjdk.java.net/jdk/pull/4236 From dcubed at openjdk.java.net Fri May 28 16:27:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 16:27:14 GMT Subject: Integrated: 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls In-Reply-To: References: Message-ID: On Fri, 28 May 2021 00:00:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to change the guarantee() calls added by JDK-8264123 to assert() calls. > See the bug report for the details. > > Tested with Mach5 Tier1. This pull request has now been integrated. Changeset: 591b0c3a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/591b0c3a463e07d2ec26047f0e61855cbfde13b6 Stats: 17 lines in 2 files changed: 4 ins; 0 del; 13 mod 8264624: change the guarantee() calls added by JDK-8264123 to assert() calls Reviewed-by: pchilanomate, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/4236 From mseledtsov at openjdk.java.net Fri May 28 16:34:03 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 28 May 2021 16:34:03 GMT Subject: RFR: 8267917: mark hotspot containers tests which ignore external VM flags In-Reply-To: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com> References: <-2xStypSXn36rLxpzahRaczKC34Oy1QvW9oZISxyNTI=.e018fe94-7a4d-4e78-9212-349546a01908@github.com> Message-ID: On Fri, 28 May 2021 08:31:49 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny and trivial patch that adds `@requires vm.flagless` to two container tests that, supposedly, ignore external VM flags? > > attn: @mseledts > > Cheers, > -- Igor Marked as reviewed by mseledtsov (Committer). Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4241 From dcubed at openjdk.java.net Fri May 28 21:45:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 21:45:29 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers Message-ID: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. Also remove errant text added by the jframeID XSL template code: // java_thread - unchecked // depth - pre-checked as non-negative The first line about `jthread` is output in error. Only the second line about `depth` should be included. This fix is tested with a Mach5 Tier1 job set. ------------- Commit messages: - 8264800: cleanup Threads_lock comments in JVM/TI function headers Changes: https://git.openjdk.java.net/jdk/pull/4254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264800 Stats: 91 lines in 3 files changed: 0 ins; 52 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/4254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4254/head:pull/4254 PR: https://git.openjdk.java.net/jdk/pull/4254 From dholmes at openjdk.java.net Fri May 28 21:56:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 21:56:17 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 21:57:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 21:57:31 GMT Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based Message-ID: The Thread-SMR project added counter based tests for various APIs. See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". Time based tests are more appropriate for stress kits so I'm updating the counter based tests to be time based instead. Two of the updated tests have shaken out failures that are tracked by: JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" These updated tests are test via Mach5 Tier[134567] (in progress). They have also been test by my Stress Kit runs for jdk-17+2[0-4]. ------------- Commit messages: - Use portable LL format from jni_tools.h for printf() with jlong. - 8266130: covert Thread-SMR stress tests from counter based to time based Changes: https://git.openjdk.java.net/jdk/pull/4237/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266130 Stats: 981 lines in 20 files changed: 396 ins; 291 del; 294 mod Patch: https://git.openjdk.java.net/jdk/pull/4237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4237/head:pull/4237 PR: https://git.openjdk.java.net/jdk/pull/4237 From xliu at openjdk.java.net Fri May 28 22:30:46 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 28 May 2021 22:30:46 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. Message-ID: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> The root cause of the intermittent failure is that _decorators in LogDecorations may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a Log output via set_log_config(TestLogFileName, "all=off"). Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. LogDecorator is a bitmask of uiint. It's even smaller than a reference on LP64 platforms. Caveat: this patch doesn't fix the race condition of update_decorators. Theorically, it may still cause an error if user dynamically enrich decorators for one log output. User can't do that via dcmd VM.log because one can't change the configuration of an established output via dcmd. ------------- Commit messages: - 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. Changes: https://git.openjdk.java.net/jdk/pull/4257/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267926 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257 PR: https://git.openjdk.java.net/jdk/pull/4257 From xliu at openjdk.java.net Fri May 28 22:39:23 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 28 May 2021 22:39:23 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Fri, 28 May 2021 22:15:14 GMT, Xin Liu wrote: > The root cause of the intermittent failure is that _decorators in LogDecorations > may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a > Log output via set_log_config(TestLogFileName, "all=off"). > > Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. > LogDecorator is a bitmask of uiint. It's even smaller than a reference on LP64 platforms. > > Caveat: this patch doesn't fix the race condition of update_decorators. Theorically, > it may still cause an error if user dynamically enrich decorators for one log output. > User can't do that via dcmd VM.log because one can't change the configuration of > an established output via dcmd. Test: I simulate the race condition in the JBS. it should work. I personally inspect all gtests, only this line make _decorators bigger than before. We haven't added async logging support for stdout/stderr yet. Therefore, it's safe, so far. ./logging/test_logConfiguration.cpp:222: set_log_config("stderr", "all=off", _all_decorators); I will consider this case when I enable stdout/stderr of async logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/4257 From duke at openjdk.java.net Fri May 28 22:42:22 2021 From: duke at openjdk.java.net (duke) Date: Fri, 28 May 2021 22:42:22 GMT Subject: Withdrawn: 8264311: Heap object statistics In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:04:57 GMT, Roman Kennke wrote: > For Lilliput evaluation, it would be useful to be able to get some statistics about heap objects, e.g. how many objects there typically are, what is their (average) size, how big is the live data set, how many objecs have an identity hash code and how many objects are locked. Some of that information may be useful for general purpose too, e.g. the avg live data set and object size/count information might be quite useful to have. > > Heap object statistics can be gathered and printed by invoking java with -XX:+UnlockDiagnosticVMOptions -XX:+HeapObjectStats -Xlog:heap+stats. It will impact performance of the workload. The sampling interval can be specificed by -XX:HeapObjectStatsSamplingInterval=X (in ms) and defaults to 500 (ms). > > Testing: > - [x] Some manual tests, verifying the plausability of the output by hand > - [ ] tier1 > - [ ] tier2 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3271 From ysuenaga at openjdk.java.net Sat May 29 01:22:21 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 29 May 2021 01:22:21 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Hmm... it looks like the same result for the user between `-f` and `-rewrite`, and also many users will be easy to imagine the result in case of `-f`. Let's see comments from other reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From darcy at openjdk.java.net Sat May 29 02:02:50 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 29 May 2021 02:02:50 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v10] In-Reply-To: References: Message-ID: > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Fix typo found by @hseigel. - Merge branch 'master' into 8266530 - Respond to review feedback. - Merge branch 'master' into 8266530 - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - Merge branch 'master' into 8266530 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8ebb37fb...faa4ef23 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/0297657a..faa4ef23 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=08-09 Stats: 26905 lines in 386 files changed: 3564 ins; 22742 del; 599 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From mli at openjdk.java.net Sat May 29 06:08:34 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 29 May 2021 06:08:34 GMT Subject: RFR: JDK-8267934: remove dead code in CLD Message-ID: JDK-8267934: remove dead code in CLD ------------- Commit messages: - JDK-8267934: remove dead code in CLD Changes: https://git.openjdk.java.net/jdk/pull/4261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4261&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267934 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4261/head:pull/4261 PR: https://git.openjdk.java.net/jdk/pull/4261 From dcubed at openjdk.java.net Sat May 29 13:21:26 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 13:21:26 GMT Subject: RFR: 8267953: restore 'volatile' to ObjectMonitor::_owner field Message-ID: A trivial fix to restore 'volatile' to ObjectMonitor::_owner field. This fix was tested with a Mach5 Tier job set. ------------- Commit messages: - 8267953: restore 'volatile' to ObjectMonitor::_owner field Changes: https://git.openjdk.java.net/jdk/pull/4262/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4262&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267953 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4262.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4262/head:pull/4262 PR: https://git.openjdk.java.net/jdk/pull/4262 From dcubed at openjdk.java.net Sat May 29 13:46:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 13:46:22 GMT Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based In-Reply-To: References: Message-ID: On Fri, 28 May 2021 00:13:25 GMT, Daniel D. Daugherty wrote: > The Thread-SMR project added counter based tests for various APIs. > See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". > > Time based tests are more appropriate for stress kits so I'm > updating the counter based tests to be time based instead. > > Two of the updated tests have shaken out failures that are tracked by: > > JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" > > JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" > > These updated tests are tested via Mach5 Tier[134567]. > They have also been test by my Stress Kit runs for jdk-17+2[0-4]. Here are my Mach5 Tier[1-7] results: Mach5 Tier1: - no failures - 25 runs of the updated tests in Tier1 Mach5 Tier2: - 1 known, unrelated failure - The updated tests don't run in Tier2. Mach5 Tier3: - 5 known, unrelated test failures - 70 runs of the updated tests Mach5 Tier4: - 17 runs of the updated tests - 2 known, unrelated test failures Mach5 Tier5: - 56 runs of the updated tests - 1 known, unrelated failure, 3 failures of the updated tests linked to the known bugs Mach5 Tier6: - 122 runs of the updated tests - 2 failures of the updated tests, linked to the known bugs Mach5 Tier7: - 151 runs of the updated tests - 1 failure of the updated tests, linked to the known bug Because of the failures in the upper tiers, when this PR is integrated I will be ProblemListing: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java 8264605 vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java 8266593 The suspendthrd003/8264605 failure had been seen one time in the CI on 2021.04.01 (April Fools Day!) and is now much more reproducible with the updated version. The popframe011/8266593 failure had never been seen before being updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4237 From coleenp at openjdk.java.net Sat May 29 15:50:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 29 May 2021 15:50:19 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Yes, looks trivial and fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4254 From dcubed at openjdk.java.net Sat May 29 16:35:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 16:35:17 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: <_Xn-IYh41j6i8Zb_Nl6FpYElGoEFEo1blJBwIOUYoFY=.24dff08f-26f2-493a-a78e-a01f90fa8ab2@github.com> On Sat, 29 May 2021 15:47:02 GMT, Coleen Phillimore wrote: >> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. >> >> Also remove errant text added by the jframeID XSL template code: >> >> >> // java_thread - unchecked >> // depth - pre-checked as non-negative >> >> >> The first line about `jthread` is output in error. >> Only the second line about `depth` should be included. >> >> This fix is tested with a Mach5 Tier1 job set. > > Yes, looks trivial and fine. @coleenp - Thanks for the fast review! Do you think I should wait for a Serviceability team member review or just integrate? I _think_ they still trust me to change comments... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From aph at openjdk.java.net Sat May 29 17:33:18 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 29 May 2021 17:33:18 GMT Subject: RFR: 8267953: restore 'volatile' to ObjectMonitor::_owner field In-Reply-To: References: Message-ID: <1UsAz1dYBoC3FUHtFC6Neth0iVdtp7jJbU2Xb1SPDQE=.c65a5cc4-3bea-4393-a805-3be0ae6b64dd@github.com> On Sat, 29 May 2021 13:15:27 GMT, Daniel D. Daugherty wrote: > A trivial fix to restore 'volatile' to ObjectMonitor::_owner field. > > This fix was tested with a Mach5 Tier job set. Yes. I very much approve. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4262 From dcubed at openjdk.java.net Sat May 29 17:49:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 17:49:22 GMT Subject: RFR: 8267953: restore 'volatile' to ObjectMonitor::_owner field In-Reply-To: <1UsAz1dYBoC3FUHtFC6Neth0iVdtp7jJbU2Xb1SPDQE=.c65a5cc4-3bea-4393-a805-3be0ae6b64dd@github.com> References: <1UsAz1dYBoC3FUHtFC6Neth0iVdtp7jJbU2Xb1SPDQE=.c65a5cc4-3bea-4393-a805-3be0ae6b64dd@github.com> Message-ID: On Sat, 29 May 2021 17:29:56 GMT, Andrew Haley wrote: >> A trivial fix to restore 'volatile' to ObjectMonitor::_owner field. >> >> This fix was tested with a Mach5 Tier job set. > > Yes. I very much approve. @theRealAph - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4262 From dcubed at openjdk.java.net Sat May 29 17:49:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 17:49:22 GMT Subject: Integrated: 8267953: restore 'volatile' to ObjectMonitor::_owner field In-Reply-To: References: Message-ID: On Sat, 29 May 2021 13:15:27 GMT, Daniel D. Daugherty wrote: > A trivial fix to restore 'volatile' to ObjectMonitor::_owner field. > > This fix was tested with a Mach5 Tier job set. This pull request has now been integrated. Changeset: 66274320 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/66274320251f492b0bba79cdfef88ad5b0d104fa Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8267953: restore 'volatile' to ObjectMonitor::_owner field Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/4262 From dholmes at openjdk.java.net Sun May 30 02:47:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 May 2021 02:47:32 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Fri, 28 May 2021 22:15:14 GMT, Xin Liu wrote: > The root cause of the intermittent failure is that _decorators in LogDecorations > may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a > Log output via set_log_config(TestLogFileName, "all=off"). > > Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. > LogDecorator is a bitmask of uiint. It's even smaller than a reference on LP64 platforms. > > Caveat: this patch doesn't fix the race condition of update_decorators. Theorically, > it may still cause an error if user dynamically enrich decorators for one log output. > User can't do that via dcmd VM.log because one can't change the configuration of > an established output via dcmd. As this is debug only this seems a reasonable workaround. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4257 From dholmes at openjdk.java.net Sun May 30 22:10:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 30 May 2021 22:10:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <002Atw8V5zaO1V3AoYbci_bhcdrHoqQFyfHYbkgIahM=.7aae1617-412b-4c4e-9292-0cc259540fb2@github.com> On Sun, 30 May 2021 19:56:52 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has updated the pull request incrementally with one additional commit since the last revision: > > Only expose non RetentionPolicy.RUNTIME annotations when -XX:+PreserveAllAnnotations is specified Hotspot changes need to be reviewed on a hotspot mailing list ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From david.holmes at oracle.com Sun May 30 23:01:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 09:01:37 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> On 31/05/2021 4:44 am, Alan Bateman wrote: > On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > I checked the pre-OpenJDK history and `-XX:+PreserveAllAnnotations` dates from when JSR-175 support was added in JDK 5. It may have been useful during the development but I don't see any tests using it now. I don't think we want to create an attractive nuisance here and maybe this XX option should be deprecated so that it can be obsoleted and eventually removed. I was a bit confused by this PR until I realized that annotations with CLASS retention policy must be represented in the classfile as RuntimeInvisible annotations - as the only affect of PreserveAllAnnotations is to make invisible annotations remain present in the runtime representation of the classfile, as allowed for by JVMS 4.7.17 (and related). As Alan notes we don't seem to have any tests (current or historical) for the operation of this flag (which is quite surprising) but its affect in the VM code is quite simple and obvious - and was recently extended to handle record attributes. I don't know what the design intent on the core reflection side was in relation to this. I could imagine a design that always asks the VM for any CLASS or RUNTIME retention annotation, knowing that the VM may have been instructed to preserve CLASS annotations. In that way the core reflection code would be oblivious to the means by which the VM was instructed to preserve said annotations. If core reflection has never exposed CLASS retention annotations even when PreserveAllAnnotations is set, then I would not support starting now. But if it is the case that only some recently added annotations are not conforming to pre-existing behaviour then I would support fixing those cases. However, given we have not previously needed to tell core reflection about the PreserveAllAnnotations flag, I would not want to start doing so now, as it should not be necessary. If PreserveAllAnnotations has hitherto been working exactly as one would expect given JVMS 4.7.17 etc, then I would certainly not support deprecating and removing it. But we should add in some tests. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From dholmes at openjdk.java.net Mon May 31 01:29:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 01:29:03 GMT Subject: RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v7] In-Reply-To: References: Message-ID: > As part of JEP 306, the vestiges of HotSpot support for non-strict floating-point execution can be removed. All methods implicitly have strictfp semantics so the explicit checks for is_strict() can be replaced by true and the code reformulated accordingly. > > There are still some names that include "strict" that could potentially be renamed to remove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into jep-306 - Remove dead code on aarch64 - Merge branch 'master' into jep-306 - The code for strict handling only applies to doubles. - Add missing space - lir_div_strictfp and lir_mul_strictfp - Removed divDPR_reg_round as it has a false predicate and so is now unused - Revert classFileParser changes as they will be handled by JDK-8266530 - 8266530: HotSpot changes for JEP 306 All methods are now implicitly strictfp so all code generation etc uses the strict form. There are still some names that include "strict" that could potentially be renamed to rmeove it, but the fact we have to have strict fp semantics is still important on some platforms, so the names help reinforce that IMO. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3991/files - new: https://git.openjdk.java.net/jdk/pull/3991/files/cc526aa4..3ce17c29 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3991&range=05-06 Stats: 38324 lines in 1589 files changed: 7901 ins; 27074 del; 3349 mod Patch: https://git.openjdk.java.net/jdk/pull/3991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3991/head:pull/3991 PR: https://git.openjdk.java.net/jdk/pull/3991 From dholmes at openjdk.java.net Mon May 31 04:55:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 04:55:42 GMT Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable Message-ID: This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block! The fix is to force resolution of the catch-type at verification time, when it is Throwable. To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue. Testing: tiers 1-3, plus the new test Thanks, David ------------- Commit messages: - 8267118: OutOfMemoryError cannot be caught as a Throwable Changes: https://git.openjdk.java.net/jdk/pull/4266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267118 Stats: 112 lines in 3 files changed: 111 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4266/head:pull/4266 PR: https://git.openjdk.java.net/jdk/pull/4266 From xliu at openjdk.java.net Mon May 31 05:54:38 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 31 May 2021 05:54:38 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v2] In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: > The root cause of the intermittent failure is that _decorators in LogDecorations > may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a > Log output via set_log_config(TestLogFileName, "all=off"). > > Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. > LogDecorator is a bitmask of uiint. It's even smaller than a reference on LP64 platforms. > > Caveat: this patch doesn't fix the race condition of update_decorators. Theorically, > it may still cause an error if user dynamically enrich decorators for one log output. > User can't do that via dcmd VM.log because one can't change the configuration of > an established output via dcmd. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4257/files - new: https://git.openjdk.java.net/jdk/pull/4257/files/0bde2876..5ad232b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=00-01 Stats: 98 lines in 6 files changed: 92 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257 PR: https://git.openjdk.java.net/jdk/pull/4257 From xliu at openjdk.java.net Mon May 31 05:54:40 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 31 May 2021 05:54:40 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v2] In-Reply-To: References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Mon, 31 May 2021 05:50:59 GMT, Xin Liu wrote: >> The root cause of the intermittent failure is that _decorators in LogDecorations >> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a >> Log output via set_log_config(TestLogFileName, "all=off"). >> >> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. >> LogDecorator is a bitmask of uiint. It's even smaller than a reference on LP64 platforms. >> >> Caveat: this patch doesn't fix the race condition of update_decorators. Theorically, >> it may still cause an error if user dynamically enrich decorators for one log output. >> User can't do that via dcmd VM.log because one can't change the configuration of >> an established output via dcmd. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. src/hotspot/share/logging/logConfiguration.cpp line 272: > 270: // After updating output's decorators, it's still safe to shrink all decorators of tagsets. > 271: // > 272: // There are 2 harzards in async logging. A flush operation guarantees to all pending messages in buffer are written hazards... I will update it in next revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/4257 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 05:58:54 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 05:58:54 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v3] In-Reply-To: References: Message-ID: <_6UOmCRmbn0sf-g1SgrV55lqd0kqIPZq3YwuOAJOnPs=.f543f365-c2ab-4bcf-9bd3-97eb24b61ea2@github.com> > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. Jaroslav Tulach has updated the pull request incrementally with two additional commits since the last revision: - Merging with test for long time existing behavior of -XX:+PreserveAllAnnotations - Test long time existing behavior of -XX:+PreserveAllAnnotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4245/files - new: https://git.openjdk.java.net/jdk/pull/4245/files/699861ef..9548a565 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=01-02 Stats: 172 lines in 1 file changed: 172 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:06:37 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:06:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Merging with test for long time existing behavior of -XX:+PreserveAllAnnotations - Test long time existing behavior of -XX:+PreserveAllAnnotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4245/files - new: https://git.openjdk.java.net/jdk/pull/4245/files/9548a565..0fd2fced Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4245&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4245/head:pull/4245 PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:11:18 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:11:18 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> References: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> Message-ID: On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote: > But we should add in some tests. Right, I was surprised by missing tests as well. I've just created a _"standalone"_ commit 0f689ea that adds such test and also shows the way I am currently using the `-XX:+PreserveAllAnnotations` flag. It [requires some tricks](https://github.com/openjdk/jdk/pull/4245/files#r642231785) with `ClassLoader` and bytecode manipulation to change the retention to `RUNTIME` and then (in combination with `-XX:+PreserveAllAnnotations`) the annotation is accessible. The test in 0f689ea is _"standalone"_ - e.g. it can be merged without my other changes. However I continue to hope the change in `Class.getAnnotation` could get in: the `-XX:+PreserveAllAnnotation` option hasn't caused any issues since Java 5 - this is the first improvement ever requested. Possibly also the last one - tests are written & the functionality works - what else could one want? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Mon May 31 06:11:19 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Mon, 31 May 2021 06:11:19 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: <4AhvezrrqEsGgjQvac9Uw0sZa1TTjpVzEX8YPvwLQsk=.c12ac5c9-e8c4-4fbe-8c5e-80105ffef298@github.com> On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 56: > 54: @Retention(RUNTIME) > 55: @AnnB > 56: public @interface AnnA_v2 { The `AltClassLoader` uses `AnnA_v2` instead of `AnnA_v1` when loading the classes and that makes (in cooperation with `-XX:+PreserveAllAnnotations` flag) the `RuntimeInvisibleAnnotation` visible. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From stefank at openjdk.java.net Mon May 31 06:37:23 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 31 May 2021 06:37:23 GMT Subject: RFR: JDK-8267934: remove dead code in CLD In-Reply-To: References: Message-ID: On Sat, 29 May 2021 06:00:37 GMT, Hamlin Li wrote: > JDK-8267934: remove dead code in CLD Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4261 From dholmes at openjdk.java.net Mon May 31 06:39:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 06:39:49 GMT Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable [v2] In-Reply-To: References: Message-ID: <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com> > This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block! > > The fix is to force resolution of the catch-type at verification time, when it is Throwable. > > To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue. > > Testing: tiers 1-3, plus the new test > > Thanks, > David David Holmes 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 8267118-oome - 8267118: OutOfMemoryError cannot be caught as a Throwable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4266/files - new: https://git.openjdk.java.net/jdk/pull/4266/files/74792185..f5718224 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4266&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4266&range=00-01 Stats: 38324 lines in 1589 files changed: 7901 ins; 27074 del; 3349 mod Patch: https://git.openjdk.java.net/jdk/pull/4266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4266/head:pull/4266 PR: https://git.openjdk.java.net/jdk/pull/4266 From rehn at openjdk.java.net Mon May 31 06:44:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 31 May 2021 06:44:20 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From david.holmes at oracle.com Mon May 31 06:53:09 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 16:53:09 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: <39a1abe6-eb97-db67-9565-d99f4dba8a00@oracle.com> Message-ID: <15f96673-d3cf-95eb-a8ed-aa2570066c2d@oracle.com> On 31/05/2021 4:11 pm, Jaroslav Tulach wrote: > On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote: > >> But we should add in some tests. > > Right, I was surprised by missing tests as well. I've just created a _"standalone"_ commit 0f689ea that adds such test and also shows the way I am currently using the `-XX:+PreserveAllAnnotations` flag. It [requires some tricks](https://github.com/openjdk/jdk/pull/4245/files#r642231785) with `ClassLoader` and bytecode manipulation to change the retention to `RUNTIME` and then (in combination with `-XX:+PreserveAllAnnotations`) the annotation is accessible. I was thinking (not for this PR of course) of something a bit more comprehensive that simply defined a class with methods/fields with both class-retention and runtime-retention attributes (there are 8 cases of "invisible" annotations IIRC) that verified their presence/absence both with and without PreserveAllAnnotation. > The test in 0f689ea is _"standalone"_ - e.g. it can be merged without my other changes. However I continue to hope the change in `Class.getAnnotation` could get in: the `-XX:+PreserveAllAnnotation` option hasn't caused any issues since Java 5 - this is the first improvement ever requested. Possibly also the last one - tests are written & the functionality works - what else could one want? I'll have to defer to core-libs folk here. As I said I would have expected the Java code to just ask the VM for the annotations applied to a given element, and that the VM would return the CLASS retention ones if PreserveAllAnnotation was set. I don't understand how the AnnotationParser is used in general and as it is not part of the VM the part of the JVMS that talks about exposing invisible annotations is not really applicable. Perhaps an oversight when this API was created, but I don't know. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From dholmes at openjdk.java.net Mon May 31 07:06:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 07:06:20 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: <5XsEmp8-WkUG9TATjla1pIlWNXPS2r37n0sM6m3Of0A=.930f8486-4575-4367-abb0-d34ee9d74c35@github.com> On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Hi Dan, I _think_ this is okay. It is rather confusing though as I couldn't figure out why some functions have the threadsList-handle as part of the code generated via the XML file, and some have it in the jvmtiEnv part of the code - e.g. compare SetThreadLocalStorage and GetThreadLocalStorage. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4254 From alanb at openjdk.java.net Mon May 31 07:10:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 31 May 2021 07:10:18 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <3zOePsWq4Kio0lgR1mfkshO5RYsbvB9GKQai7emntYs=.3e205c99-0fdf-46b1-8213-74699237babd@github.com> On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. I don't know anything about JavaScriptBody but this reads like they declared their annotations to have CLASS retention when they should have used RUNTIME retention. There's something very uncomfortable with changing the JDK as a workaround and telling JavaScriptBody users that you need to run with +PreserveAllAnnotations to get correct behavior. I would be concerned that leads to frameworks requesting it be the default so they can avoid parsing class files. @dougxc @vnkozlov Has there been any other cases where the Graal compiler has needed to get access to the class files? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From mdoerr at openjdk.java.net Mon May 31 08:32:26 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 31 May 2021 08:32:26 GMT Subject: Integrated: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. This pull request has now been integrated. Changeset: 1e29005a Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/1e29005a22c7951242cf3b0d8cf2e6adc0b7b315 Stats: 12 lines in 2 files changed: 4 ins; 0 del; 8 mod 8267842: SIGSEGV in get_current_contended_monitor Reviewed-by: stefank, dcubed, ysuenaga, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Mon May 31 08:32:26 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 31 May 2021 08:32:26 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Mon May 31 08:38:23 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 31 May 2021 08:38:23 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Agree, I would like to hear more feedback. I still don't think we need to provide a (false) similarity with existing tools. For example: * `cp` succeeds if the target file exists; `jcmd` bails out in this case * `cp -f` unlinks and creates a new file (so it is just a convenient substitution to `rm -f; cp`); `jcmd -rewrite` rewrites the file -- this cannot be achieved without making changes to the Hotspot. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From dnsimon at openjdk.java.net Mon May 31 09:06:21 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 31 May 2021 09:06:21 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. There is [support for parsing class files in Graal](https://github.com/oracle/graal/blob/89e4cfc7ae/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/ClassfileBytecodeProvider.java#L45-L47) which exists to avoids all bytecode preprocessing and instrumentation that may be performed on the VM internal bytecode representation. This is only done for trusted bytecode that comes from Graal classes (e.g. [Java source code snippets](https://github.com/oracle/graal/blob/89e4cfc7ae/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/AllocationSnippets.java#L50-L72) used to express compiler (sub)graphs as Java source code). ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From tschatzl at openjdk.java.net Mon May 31 09:40:30 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 31 May 2021 09:40:30 GMT Subject: RFR: JDK-8267934: remove dead code in CLD In-Reply-To: References: Message-ID: On Sat, 29 May 2021 06:00:37 GMT, Hamlin Li wrote: > JDK-8267934: remove dead code in CLD Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4261 From plevart at openjdk.java.net Mon May 31 10:29:23 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 10:29:23 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing usages (Post Processing Classes, Instrumentation Agent, Special classloading, etc.) of the annotation performed the manipulation on `.class` files. However recently a new use-case relying on JVMCI appeared. JVMCI is working on "live" classes and doesn't provide access to the `.class` files (as far as I know, CCing @dougxc). Using `-XX:+PreserveAllAnnotation` solved the first part of problem - the HotSpot code loaded the `RuntimeInvisibleAnnotations`"in". The second part was solved by on the fly patching of `@JavaScriptBody` class to claim to have`RetentionPolicy.RUNTIME`. That part is a bit tricky, so I created this pull request for your consideration. > > Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. Hi Jaroslav, If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From plevart at openjdk.java.net Mon May 31 10:36:20 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 10:36:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. I think it would be wrong to extend the meaning of `-XX:+PreserveAllAnnotations` to the AnnotationParser so it would return CLASS retention-marked annotations. `-XX:+PreserveAllAnnotations` is just disabling the JVM optimization and it is not meant to be "visible" in the Java code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From vladimir.x.ivanov at oracle.com Mon May 31 11:19:39 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 31 May 2021 14:19:39 +0300 Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: >> Do you think additional comments can improve the situation? > > I was thinking more of restoring something to the readme. Does it look better? https://github.com/openjdk/jdk/pull/4008/commits/66cda654f93e30ad1a6b72c29fb83e84c1a7ae58 Best regards, Vladimir Ivanov From mli at openjdk.java.net Mon May 31 11:20:23 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 31 May 2021 11:20:23 GMT Subject: RFR: JDK-8267934: remove dead code in CLD In-Reply-To: References: Message-ID: <0CDpjqoVtrek-LCiLt4PjCCoa9zKCzrlD53pBjT0r5c=.d4e1f87a-4106-4926-b059-81ed2205ec99@github.com> On Mon, 31 May 2021 06:34:00 GMT, Stefan Karlsson wrote: >> JDK-8267934: remove dead code in CLD > > Marked as reviewed by stefank (Reviewer). @stefank @tschatzl Thansk for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4261 From mli at openjdk.java.net Mon May 31 11:20:24 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 31 May 2021 11:20:24 GMT Subject: Integrated: JDK-8267934: remove dead code in CLD In-Reply-To: References: Message-ID: On Sat, 29 May 2021 06:00:37 GMT, Hamlin Li wrote: > JDK-8267934: remove dead code in CLD This pull request has now been integrated. Changeset: 4ade125c Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/4ade125c8a53e0bdc105e5f65e8c1d7aa13db950 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8267934: remove dead code in CLD Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/4261 From vlivanov at openjdk.java.net Mon May 31 11:23:04 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 31 May 2021 11:23:04 GMT Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v4] In-Reply-To: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: > Miscellaneous refactorings/cleanups in `vm.runtime.defmeth` tests. > > In particular: > - replace `test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/scenarios` with enumeration of different test configurations in tests themselves; > - pass `TestBuilder` as a parameter and initiate test execution from executor; > - switch max class file version tested from 52 to 61 (`V17`); > - minor changes (cleanups, new test cases) > > Testing: > - [x] vmTestbase/vm/runtime/defmeth/ > - [x] hs-tier5-rt - hs-tier8-rt Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Improve README ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4008/files - new: https://git.openjdk.java.net/jdk/pull/4008/files/bcba4283..66cda654 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4008&range=02-03 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4008.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4008/head:pull/4008 PR: https://git.openjdk.java.net/jdk/pull/4008 From plevart at openjdk.java.net Mon May 31 12:05:23 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 12:05:23 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. >> >> This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. > > Jaroslav Tulach has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. A suggestion for this RFR. Maybe the title of the issue could be rephrased as: "Add a test for -XX+PreserveAllAnnotations option" A test could be constructed so that it would mimic the migration of an annotation from CLASS to RUNTIME retention by using separate compilation of: 1. an annotation with CLASS retention together with a class that uses it to annotate itself 2. the same type of annotation but with RUNTIME retention The test would use a class from compilation (1) combined with annotation from compilation (2) together with `-XX+PreserveAllAnnotations` JVM option to verify that the annotation is visible via reflection. No ClassLoader magic is necessary. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From tschatzl at openjdk.java.net Mon May 31 12:12:25 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 31 May 2021 12:12:25 GMT Subject: RFR: JDK-8267839: trivial mem leak in numa In-Reply-To: References: Message-ID: <9tNfLw69ARW81P5xjvOsC_xW_qJAiqBV0xnx64CKRho=.efc078f4-0bdc-4c63-808e-8a7f8963c5ba@github.com> On Thu, 27 May 2021 08:46:00 GMT, Hamlin Li wrote: > There is a trivial mem leak in numa related code. This patch is to use a stored bitmask* rather than get a new one. Lgtm. Please wait for a second reviewer, preferably from the runtime team, before pushing this. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4219 From david.holmes at oracle.com Mon May 31 12:35:54 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 22:35:54 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2] In-Reply-To: References: Message-ID: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> On 31/05/2021 8:29 pm, Peter Levart wrote: > On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: > >> My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing usages (Post Processing Classes, Instrumentation Agent, Special classloading, etc.) of the annotation performed the manipulation on `.class` files. However recently a new use-case relying on JVMCI appeared. JVMCI is working on "live" classes and doesn't provide access to the `.class` files (as far as I know, CCing @dougxc). Using `-XX:+PreserveAllAnnotation` solved the first part of problem - the HotSpot code loaded the `RuntimeInvisibleAnnotations`"in". The second part was solved by on the fly patching of `@JavaScriptBody` class to claim to have`RetentionPolicy.RUNTIME`. That part is a bit tricky, so I created this pull request for your consideration. >> >> Obvious suggestion is to change the `@JavaScriptBody` retention to `RUNTIME` - however there are plenty of libraries already compiled with the existing annotation and they would have to be all recompiled to new version. I'd rather avoid that and that's another reason why I decided to bring the `-XX:+PreserveAllAnnotation` to your attention and propose to improve it. > > Hi Jaroslav, > > If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... > > I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. That reads backwards to me. +PreserveAllAnnotations means that CLASS retention annotations are retained by the VM not just RUNTIME ones. So in that sense it might be a migration aid if moving from RUNTIME to CLASS, not CLASS to RUNTIME. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From david.holmes at oracle.com Mon May 31 12:40:29 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 May 2021 22:40:29 +1000 Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> Message-ID: <1624303d-7449-320f-c0ec-e0acc65e1c1b@oracle.com> On 31/05/2021 9:19 pm, Vladimir Ivanov wrote: >>> Do you think additional comments can improve the situation? >> >> I was thinking more of restoring something to the readme. > > Does it look better? > > > https://github.com/openjdk/jdk/pull/4008/commits/66cda654f93e30ad1a6b72c29fb83e84c1a7ae58 Yes thanks. So these tests will now be updated on each release to update the max version? David ----- > > Best regards, > Vladimir Ivanov From tschatzl at openjdk.java.net Mon May 31 12:40:18 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 31 May 2021 12:40:18 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:46:29 GMT, Stefan Johansson wrote: >> Please review this change to fix the large page testing on Windows. >> >> **Summary** >> The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). >> >> When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. >> >> The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. >> >> **Testing** >> Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Albert review. Harden test to not allow failure for request address Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4090 From sjohanss at openjdk.java.net Mon May 31 12:54:25 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 31 May 2021 12:54:25 GMT Subject: RFR: 8266807: Windows os_windows-gtest broken for UseLargePages [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 09:15:20 GMT, Ivan Walulya wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Albert review. Harden test to not allow failure for request address > > lgtm! Thanks @walulyai, @albertnetymk and @tschatzl for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/4090 From sjohanss at openjdk.java.net Mon May 31 12:54:26 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 31 May 2021 12:54:26 GMT Subject: Integrated: 8266807: Windows os_windows-gtest broken for UseLargePages In-Reply-To: References: Message-ID: <0Qr0ZpVwcYSZLNctLBkn9ZbiC8qzgU3Uso55lSMaRAg=.979f480a-bb13-493d-a88f-581e188d287c@github.com> On Tue, 18 May 2021 11:08:50 GMT, Stefan Johansson wrote: > Please review this change to fix the large page testing on Windows. > > **Summary** > The comparisons in the test check for reservations `!= NULL` and consider that a failed reservation, that is incorrect. This leads to the test never really doing anything. When `UseLargePages` is false, the test is skipped and when true and the user is configured with lock permissions (needed to use large pages), the test is skipped after the first allocation (since it is wrongly seen as a failure). > > When a user doesn't have permissions to lock memory, the JVM will turn off large pages so this will be the same as running with `-UseLargePages`. > > The test has been changed to skip testing if the first large page reservation fail, similar to what was intended before. After that the rest of the reservations are expected to pass, apart from the reservation trying to reserve in an already existing reservation. > > **Testing** > Manual testing on a Windows host with and without large pages enabled. Also tested through mach5. This pull request has now been integrated. Changeset: 5df25dc0 Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/5df25dc088cfc3069e451b48c4f013d1d0491aa2 Stats: 23 lines in 1 file changed: 11 ins; 1 del; 11 mod 8266807: Windows os_windows-gtest broken for UseLargePages Reviewed-by: iwalulya, ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/4090 From vladimir.x.ivanov at oracle.com Mon May 31 13:00:05 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 31 May 2021 16:00:05 +0300 Subject: RFR: 8267095: Miscellaneous cleanups in vm.runtime.defmeth tests [v2] In-Reply-To: <1624303d-7449-320f-c0ec-e0acc65e1c1b@oracle.com> References: <0seUMFKF-ui1N-7qeOIzVa9dhPPpWQtPfz5xqumiGtk=.570c6b3f-7edb-4e11-b6c5-35471527f0f8@github.com> <1624303d-7449-320f-c0ec-e0acc65e1c1b@oracle.com> Message-ID: <289eca07-8342-1a77-f1fb-b418585debe4@oracle.com> >> Does it look better? >> https://github.com/openjdk/jdk/pull/4008/commits/66cda654f93e30ad1a6b72c29fb83e84c1a7ae58 > > > Yes thanks. > > So these tests will now be updated on each release to update the max > version? Yes. (It is desirable, but not strictly required.) I also thought about other options (either (1) automatically detect maximally supported major class file version; or (2) introduce a central place in test library to expose the value), but decided to leave it for a future enhancement. Best regards, Vladimir Ivanov From xliu at openjdk.java.net Mon May 31 17:09:48 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 31 May 2021 17:09:48 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v3] In-Reply-To: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: > The root cause of the intermittent failure is that _decorators in LogDecorations > may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a > Log output via set_log_config(TestLogFileName, "all=off"). > > Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. > LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms. > > This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952. > Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. > This patch also adds a storestore barrier to make sure it's safe on weak consistency machines. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Increase reader's counter before creating LogDecoration. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4257/files - new: https://git.openjdk.java.net/jdk/pull/4257/files/5ad232b2..3b2d7636 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4257&range=01-02 Stats: 10 lines in 3 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4257/head:pull/4257 PR: https://git.openjdk.java.net/jdk/pull/4257 From plevart at openjdk.java.net Mon May 31 17:56:26 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 17:56:26 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > > Hi Jaroslav, > > If you change `@JavaScriptBody` retention to `RUNTIME`, you don't need to re-compile any code that uses this annotation. You just have to use `-XX:+PreserveAllAnnotations` to expose all anotations to JVM and consequently to AnnotationParser. The parser will then return just the `RUNTIME` retention-marked annotations. This means you just have to run the app with the version of the JavaScriptBody.class that is retention-marked as `RUNTIME`... > > I think that `-XX:+PreserveAllAnnotations` was meant as a migration aid for exactly the case when some annotations migrate from `CLASS` to `RUNTIME` retention and libraries using such annotations are not re-compiled yet. > > That reads backwards to me. +PreserveAllAnnotations means that CLASS > retention annotations are retained by the VM not just RUNTIME ones. So > in that sense it might be a migration aid if moving from RUNTIME to > CLASS, not CLASS to RUNTIME. > > David Why? If an annotation has a CLASS retention when some source that uses it is compiled, such annotation usage is compiled into the `RuntimeInvisibleAnnotations` attribute of the class that corresponds to the source that uses the annotation. So when later the annotation is migrated to have RUNTIME retention, the AnnotationParser would return such annotation if only its encoded bytestream has been given to it. But since it is present in the `RuntimeInvisibleAnnotations` attribute of the class that uses such annotation, by default it is not (only `RuntimeVisibleAnnotations` attribute annotations are passed to AnnotationParser). Unless you give JVM the `-XX:+PreserveAllAnnotations` option to also preserve (in its internal structures) all annotations (from `RuntimeVisibleAnnotations` and `RuntimeInvisibleAnnotations` attributes). So in that case, the AnnotationParser has a chance to parse such "migrated" annotation for which the usages have not been recompiled yet. When such usages get re compiled, such annotation uses will get compiled into `RuntimeVisibleAnnotations` attribute(s) of classes that use the annotation and the option will not be needed any more... This is how I understand the JVM option. I might be wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From plevart at openjdk.java.net Mon May 31 18:20:22 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 18:20:22 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > That reads backwards to me. +PreserveAllAnnotations means that CLASS > retention annotations are retained by the VM not just RUNTIME ones. So > in that sense it might be a migration aid if moving from RUNTIME to > CLASS, not CLASS to RUNTIME. > > David Ah, I know why you think that way. You think that when an annotation is migrated from RUNTIME to CLASS retention, that some users would still want to "see" it via reflection (at runtime)... No, I don't think this was the intention of the JVM option. Migrating from RUNTIME to CLASS retention means that the ways of looking up such annotation are shrinking. Such change to the annotation should only be attempted when there are no more runtime lookups to support. So 1st deprecation of RUNTIME retention on the annotation should be published, followed by change to CLASS retention. OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From xliu at openjdk.java.net Mon May 31 19:56:20 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 31 May 2021 19:56:20 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v3] In-Reply-To: References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Sun, 30 May 2021 02:44:11 GMT, David Holmes wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Increase reader's counter before creating LogDecoration. > > As this is debug only this seems a reasonable workaround. > > Thanks, > David Hi, @dholmes-ora, I recently realize how flexible unified logging is(JDK-8267952). By design, `LogConfiguration::configure_output` is MT-safe. Clearly, authors of unified logging put a lot of thoughts on it. I try to write down my understanding in the form of comments. Async logging support can be a natural extension of current synchronous logging. All we need to do is to eliminate two hazards I mentioned. I also add a concurrent test to prove it works. By reasoning how it works and the test, I discover two places which could cause race condition. they are also fixed in this patch. 1) the creation of LogDecorations needs to increase reader counter first. 2) need a storestore barrier to guarantee it works on weak consistency machines. Could you verify this patch in Tier4 tests? Could you also review this patch again? thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/4257 From xliu at openjdk.java.net Mon May 31 20:01:23 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 31 May 2021 20:01:23 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v3] In-Reply-To: References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Mon, 31 May 2021 17:09:48 GMT, Xin Liu wrote: >> The root cause of the intermittent failure is that _decorators in LogDecorations >> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a >> Log output via set_log_config(TestLogFileName, "all=off"). >> >> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. >> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms. >> >> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952. >> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. >> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Increase reader's counter before creating LogDecoration. Now the failure is irrelevant. It can't find proper toolchains on windows aarch64. ------------- PR: https://git.openjdk.java.net/jdk/pull/4257 From darcy at openjdk.java.net Mon May 31 21:47:58 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 31 May 2021 21:47:58 GMT Subject: RFR: 8266530: HotSpot changes for JEP 306 [v11] In-Reply-To: References: Message-ID: <9eipMQqVV-t7CCbBX0Cm-kVNK3NKiRlOQuYp-iTRUlQ=.d0f41047-57f9-45e7-bb1d-54d81d0c4f10@github.com> > Please review these VM changes in support of JEP 306: Restore Always-Strict Floating-Point Semantics. > > JEP 306 is considering the following changes to the JVMS: > > 1) Require "strict" floating-point evaluation in all circumstances. > 2) For class file version 61 and higher, undefine ACC_STRICT, moving that bit position back to undefined for methods. For class file versions, 46 through, ACC_STRICT would remain a defined modifier. > > Since all floating-point evaluation is done strictly, a modifier bit is not needed to indicate this anymore. There are a few mandated modifier checks when ACC_STRICT is defined, such as not allowing an "abstract strictfp" method. These checks in classFileParser are now conditional on the class file version. > > The tests verify "abstract strictfp" triggers a ClassFormatError for version 60 and does not trigger an error or exception for version 61. (As an undefined bit in version 61, the VM is supposed to ignore it.) > > FYI, the javac and core libs portions of JEP 306 are out for review under https://github.com/openjdk/jdk/pull/3831. > > The HotSpot and javac/core libs parts of JEP 306 are independent in that neither relies on the other: > * javac will not output class files which expose the difference in class parsing behavior; the ACC_STRICT modifier will not be set in any version 61 class file emitted by javac. > * since HotSpot already does all floating-point evaluation strictly, no changes are needed to support strict evaluation. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Merge branch 'master' into 8266530 - Fix typo found by @hseigel. - Merge branch 'master' into 8266530 - Respond to review feedback. - Merge branch 'master' into 8266530 - Restore previous is_strict cdoe in method.hpp. - Merge branch 'master' into 8266530 - Make methods strict on IA32. - ... and 4 more: https://git.openjdk.java.net/jdk/compare/58efeea3...e1acb870 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3891/files - new: https://git.openjdk.java.net/jdk/pull/3891/files/faa4ef23..e1acb870 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3891&range=09-10 Stats: 2759 lines in 319 files changed: 1575 ins; 534 del; 650 mod Patch: https://git.openjdk.java.net/jdk/pull/3891.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3891/head:pull/3891 PR: https://git.openjdk.java.net/jdk/pull/3891 From dholmes at openjdk.java.net Mon May 31 22:30:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 22:30:28 GMT Subject: RFR: 8267926: AsyncLogGtest.java fails on assert with: decorator was not part of the decorator set specified at creation. [v3] In-Reply-To: References: <5hNAMT5k2HZI2YgmAeqaGMr10DakNXn54AjbfpTULjk=.21aa0ff3-75b4-4a1b-bed7-9dab78bbacd6@github.com> Message-ID: On Mon, 31 May 2021 17:09:48 GMT, Xin Liu wrote: >> The root cause of the intermittent failure is that _decorators in LogDecorations >> may be inconsistent with LogOutput::_decorators. It could happen when gtest disables a >> Log output via set_log_config(TestLogFileName, "all=off"). >> >> Since we copy the entire logDecorations, it's reasonable to copy _decorator as well. >> LogDecorator is a bitmask of uint. It's even smaller than a reference on LP64 platforms. >> >> This patch not only fixes intermittent crash in JDK-8267926, but also fixes JDK-8267952. >> Two hazards of async logging in `LogConfiguration::configure_output` are eliminated. >> This patch also adds a storestore barrier to make sure it's safe on weak consistency machines. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Increase reader's counter before creating LogDecoration. A few comments below - mostly typos - but I think the main race still exists. I need more time to try and digest the other changes and understand the existing MT-safety aspects. Meanwhile I've submitted for tiers 1-4 testing. Thanks, David src/hotspot/share/logging/logAsyncWriter.cpp line 105: > 103: > 104: if (*counter > 0) { > 105: LogDecorations decorations(LogLevel::Warning, none::tagset(), LogDecorators::All); This looks odd to use LogDecorators::All - what exactly will that produce? src/hotspot/share/logging/logConfiguration.cpp line 266: > 264: // see the new tags and decorators. It's worth noting that the synchronization happens even level doesn't change. > 265: // > 266: // LogDecorator is a set of decorators represented in a uint. sizeof(uinit) is not greater than a machine word, Typo: uinit src/hotspot/share/logging/logConfiguration.cpp line 267: > 265: // > 266: // LogDecorator is a set of decorators represented in a uint. sizeof(uinit) is not greater than a machine word, > 267: // so store of it is atomic on the mainstream processors. I.e. readers see either its older value or new value. We should use Atomic::store and Atomic::load regardless. src/hotspot/share/logging/logConfiguration.cpp line 273: > 271: // > 272: // There are 2 hazards in async logging. A flush operation guarantees to all pending messages in buffer are written > 273: // before returning. Therefore, the hardards won't appear. It's a nop if async logging is not set. Typo: hardards src/hotspot/share/logging/logConfiguration.cpp line 279: > 277: // > 278: AsyncLogWriter::flush(); > 279: As soon as this completes, new logging requests could have been enqueued, thus restoring the hazard. src/hotspot/share/logging/logDecorators.cpp line 30: > 28: template > 29: struct AllBitmask { > 30: // Use recursive template deduction to calculcate the bitmask of all decorations. typo: calculcate ------------- PR: https://git.openjdk.java.net/jdk/pull/4257 From david.holmes at oracle.com Mon May 31 22:35:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Jun 2021 08:35:04 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: <77371781-b7f8-f2b0-8299-f56f485fd222@oracle.com> Message-ID: On 1/06/2021 4:20 am, Peter Levart wrote: > On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: > >> That reads backwards to me. +PreserveAllAnnotations means that CLASS >> retention annotations are retained by the VM not just RUNTIME ones. So >> in that sense it might be a migration aid if moving from RUNTIME to >> CLASS, not CLASS to RUNTIME. >> >> David > > Ah, I know why you think that way. You think that when an annotation is migrated from RUNTIME to CLASS retention, that some users would still want to "see" it via reflection (at runtime)... Yes. > No, I don't think this was the intention of the JVM option. Migrating from RUNTIME to CLASS retention means that the ways of looking up such annotation are shrinking. Such change to the annotation should only be attempted when there are no more runtime lookups to support. So 1st deprecation of RUNTIME retention on the annotation should be published, followed by change to CLASS retention. > > OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. That sounds like the code that wants to inspect the annotations is using knowledge that the target classes have been updated (in terms of the source change from CLASS to RUNTIME) but it only has access to old binaries. That scenario doesn't really make sense to me. In any case the operation of the flag is very simple and has no bearing on how AnnotationParser works. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4245 > From coleenp at openjdk.java.net Mon May 31 22:35:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 31 May 2021 22:35:28 GMT Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable [v2] In-Reply-To: <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com> References: <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com> Message-ID: On Mon, 31 May 2021 06:39:49 GMT, David Holmes wrote: >> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block! >> >> The fix is to force resolution of the catch-type at verification time, when it is Throwable. >> >> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue. >> >> Testing: tiers 1-3, plus the new test >> >> Thanks, >> David > > David Holmes 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 8267118-oome > - 8267118: OutOfMemoryError cannot be caught as a Throwable This seems reasonable to me. src/hotspot/share/oops/method.cpp line 232: > 230: if (do_logging) { > 231: ResourceMark rm(THREAD); > 232: log_info(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"", I think these should be log_debug, since this is useful for debugging but many people outside of hotspot engineers use -Xlog:exceptions. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4266 From david.holmes at oracle.com Mon May 31 22:40:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Jun 2021 08:40:03 +1000 Subject: RFR: 8267118: OutOfMemoryError cannot be caught as a Throwable [v2] In-Reply-To: References: <69zfXZXVcSvodLPZSFtcs8lDg00PMZ02GwmLu_rzGto=.95998bb4-ba9a-49b1-95cb-43cebcf26b5a@github.com> Message-ID: <54fd62ad-d79b-1a2f-7a33-0899b5760e7d@oracle.com> Hi Coleen, On 1/06/2021 8:35 am, Coleen Phillimore wrote: > On Mon, 31 May 2021 06:39:49 GMT, David Holmes wrote: > >>> This interesting little quirk was discovered by @iklam. During verification, the catch-type in a catch clause is normally resolved as part of being checked to see that it is a subclass of Throwable. At runtime when an exception is thrown, we also have to check if the exception being thrown is assignable to the catch-type and so handled by that catch block. For the case where the catch-type is Throwable itself, the verification subclass check trivially passes (due to a name match) without actually resolving the CP entry for the catch-type. So at runtime when the exception is thrown we have to perform the CP resolution of the catch-type. But the resolution process itself can trigger exceptions and in particular if we have thrown OutOfMemoryError, the resolution may throw a secondary OutOfMemoryError, which prevents the first from being caught by the catch block! >>> >>> The fix is to force resolution of the catch-type at verification time, when it is Throwable. >>> >>> To aid in debugging the original problem I've also added some new logging statements that show how we find a catch block and if we encounter further exceptions in trying to catch the exception - see example in the JBS issue. >>> >>> Testing: tiers 1-3, plus the new test >>> >>> Thanks, >>> David >> >> David Holmes 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 8267118-oome >> - 8267118: OutOfMemoryError cannot be caught as a Throwable > > This seems reasonable to me. Thanks for taking a look. > src/hotspot/share/oops/method.cpp line 232: > >> 230: if (do_logging) { >> 231: ResourceMark rm(THREAD); >> 232: log_info(exceptions)("Looking for catch handler for exception of type \"%s\" in method \"%s\"", > > I think these should be log_debug, since this is useful for debugging but many people outside of hotspot engineers use -Xlog:exceptions. Every existing piece of logging for exceptions is done at Info level. If throwing is logged at Info, shouldn't catching also be logged at Info? Thanks, David > ------------- > > Changes requested by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4266 > From plevart at openjdk.java.net Mon May 31 23:55:20 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 31 May 2021 23:55:20 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Mon, 31 May 2021 22:36:52 GMT, David Holmes wrote: > > OTOH when CLASS retention is changing to RUNTIME, such as in this case, the ways of looking up are widening (there is some new desire to lookup the annotation at runtime via reflection). To facilitate that, the annotation maintainer changes the retention to RUNTIME. But unfortunately, old uses of the annotation are baked in the ` RuntimeInvisibleAnnotations` attributes of the classes that were compiled with the old version of the annotation when the retention was still CLASS. Until all such classes are recompiled, the JVM option can be used to make such annotation usages visible at runtime. That makes more sense to me. > > That sounds like the code that wants to inspect the annotations is using > knowledge that the target classes have been updated (in terms of the > source change from CLASS to RUNTIME) but it only has access to old > binaries. That scenario doesn't really make sense to me. The code that wants to inspect the annotation knows that the annotation itself has been updated from CLASS to RUNTIME retention and is running with the new version of annotation on classpath. But the uses of that annotation are in other code - neither in the code that wants to inspect the annotation nor in the code that represents the annotation declaration and holds the @Retention meta-annotation use. The code that uses the annotation is the code that has been compiled before the annotation has been updated and therefore keeps annotation uses in the `RuntimeInvisibleAnnotations` attributes of class files representing that code. To be more concrete, let's illustrate with the example: // annotation_v1.jar @Retention(CLASS) public @interface Ann {} // use.jar (compiled with annotation_v1.jar on classpath, // so Use.class encodes the @Ann use in the `RuntimeInvisibleAnnotations` attribute) @Ann public class Use {} // annotation_v2.jar (the new version of annotation that migrated to RUNTIME retention) @Retention(RUNTIME) public @interface Ann {} // main.jar (running with: -cp use.jar:annotation_v2.jar:main.jar -XX:+PreserveAllAnnotations) public class Main { public static void main(String[] a) { Ann ann = Use.class.getAnnotation(Ann.class); ... } } > > In any case the operation of the flag is very simple and has no bearing > on how AnnotationParser works. Exactly. It does affect which encoded annotation data is passed to AnnotationParser though. Either just `RuntimeVisibleAnnotations` or both `RuntimeVisibleAnnotations` and `RuntimeInvisibleAnnotations`. In any case the parser filters out annotations that don't have the RUNTIME retention in their declaration. > > Cheers, > David Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4245