From mseledtsov at openjdk.org Wed Mar 1 00:07:04 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 1 Mar 2023 00:07:04 GMT Subject: RFR: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 20:18:21 GMT, Leonid Mesnik wrote: > Some old nsk code is removed, and logging is moved to the based class. > No functional changes. Marked as reviewed by mseledtsov (Committer). Looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/12777 From lmesnik at openjdk.org Wed Mar 1 00:54:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 00:54:15 GMT Subject: Integrated: 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 22:15:18 GMT, Leonid Mesnik wrote: > The solution proposed by Stefan K > > The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases. > > The fix also move > 'output = new OutputAnalyzer(this.process);' > in method xrun() to be able to try to print them in waitFor is failed/interrupted. This pull request has now been integrated. Changeset: 1fdaf252 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/1fdaf252b6375773072e665fd5d4cfb509e98f4c Stats: 29 lines in 2 files changed: 16 ins; 3 del; 10 mod 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Reviewed-by: dholmes, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12751 From fparain at openjdk.org Wed Mar 1 03:07:07 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 1 Mar 2023 03:07:07 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> Message-ID: <7pxGZNzeJsZjubOz-x7tle8naI-r4ugDLkGBKUE8Yjo=.efe9c5ee-0e64-4e35-8bf0-f6775b9374f4@github.com> On Sat, 25 Feb 2023 02:36:36 GMT, David Holmes wrote: >> If we have a default value for the char* DCmdArgument we copy it into the `_value` field using `parse_value` to make a copy in C-heap. If we then parse an actual argument value, we replace the default but don't free it. The parse method needs to use realloc. >> >> Thanks to @jcking for spotting the cause. >> >> Testing: tiers 1-3 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update test coverage for the empty and null cases Marked as reviewed by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12737 From dholmes at openjdk.org Wed Mar 1 04:23:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 04:23:12 GMT Subject: RFR: 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. [v5] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 23:11:27 GMT, Leonid Mesnik wrote: >> The solution proposed by Stefan K >> >> The startProcess() might wait forever for the expected line if the process exits (failed to start). It makes sense to just fail earlier in such cases. >> >> The fix also move >> 'output = new OutputAnalyzer(this.process);' >> in method xrun() to be able to try to print them in waitFor is failed/interrupted. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - latch != updated > - message improved We are seeing large numbers of failures after this change was integrated, so it will likely need to be backed out. ------------- PR: https://git.openjdk.org/jdk/pull/12751 From lmesnik at openjdk.org Wed Mar 1 04:51:45 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 04:51:45 GMT Subject: RFR: 8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Message-ID: The backout for 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. ------------- Commit messages: - [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Changes: https://git.openjdk.org/jdk/pull/12799/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12799&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303421 Stats: 29 lines in 2 files changed: 3 ins; 16 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12799.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12799/head:pull/12799 PR: https://git.openjdk.org/jdk/pull/12799 From dholmes at openjdk.org Wed Mar 1 04:51:46 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 04:51:46 GMT Subject: RFR: 8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 04:40:28 GMT, Leonid Mesnik wrote: > The backout for 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Backout appears okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12799 From dholmes at openjdk.org Wed Mar 1 05:19:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 05:19:05 GMT Subject: RFR: 8301106 allow cds interned strings to be moved by gc [v4] In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 21:49:08 GMT, Ioi Lam wrote: >> **Background:** >> >> Currently, the archived java strings are mapped in the G1 "[closed archive](https://github.com/openjdk/jdk/blob/574b48c6925ebfb31345fc46c7d23aa4153f99b0/src/hotspot/share/gc/g1/heapRegionType.hpp#L80-L92)" region. This essentially pins all the strings in memory. >> >> As a prerequisite for ([JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263)), this PR removes the requirement of pinning the archived strings. This will allow the CDS archive heap to be mapped in garbage collectors that do not support object pinning. >> >> **Code changes:** >> >> - The archived strings are referenced through an objArray (`_shared_strings_array`) to keep them alive. As a result, it's no longer necessary to pin them. >> - Since it's possible for the GC to move these strings, the `_shared_table` in stringTable.cpp is modified to store a 32-bit index for each archived string. This index is used to retrieve the archived string from `_shared_strings_array` at runtime. >> >> Note that CDS has a limit on the size of archived objArrays. When there's a large number of strings, we use a two-level table. See the comments around `_shared_strings_array` in the header file. >> >> **Testing** >> >> Tiers 1 - 4 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra and @dholmes-ora review -- better assert and error checking for large objects; added StringTable::verify_secondary_array_index_bits() Nothing further from me. Changes look good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12607 From lmesnik at openjdk.org Wed Mar 1 05:25:09 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 05:25:09 GMT Subject: Integrated: 8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 04:40:28 GMT, Leonid Mesnik wrote: > The backout for 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. This pull request has now been integrated. Changeset: 3aeefbf1 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/3aeefbf1defe95113a8abe3d3d11fdf3205bfd3b Stats: 29 lines in 2 files changed: 3 ins; 16 del; 10 mod 8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12799 From dholmes at openjdk.org Wed Mar 1 05:32:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 05:32:10 GMT Subject: RFR: 8301106 allow cds interned strings to be moved by gc [v4] In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 21:49:08 GMT, Ioi Lam wrote: >> **Background:** >> >> Currently, the archived java strings are mapped in the G1 "[closed archive](https://github.com/openjdk/jdk/blob/574b48c6925ebfb31345fc46c7d23aa4153f99b0/src/hotspot/share/gc/g1/heapRegionType.hpp#L80-L92)" region. This essentially pins all the strings in memory. >> >> As a prerequisite for ([JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263)), this PR removes the requirement of pinning the archived strings. This will allow the CDS archive heap to be mapped in garbage collectors that do not support object pinning. >> >> **Code changes:** >> >> - The archived strings are referenced through an objArray (`_shared_strings_array`) to keep them alive. As a result, it's no longer necessary to pin them. >> - Since it's possible for the GC to move these strings, the `_shared_table` in stringTable.cpp is modified to store a 32-bit index for each archived string. This index is used to retrieve the archived string from `_shared_strings_array` at runtime. >> >> Note that CDS has a limit on the size of archived objArrays. When there's a large number of strings, we use a two-level table. See the comments around `_shared_strings_array` in the header file. >> >> **Testing** >> >> Tiers 1 - 4 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra and @dholmes-ora review -- better assert and error checking for large objects; added StringTable::verify_secondary_array_index_bits() src/hotspot/share/classfile/stringTable.hpp line 136: > 134: > 135: // make sure _secondary_array_index_bits is not too big > 136: static void verify_secondary_array_index_bits() PRODUCT_RETURN; This needs to be NOT_DEBUG_RETURN, as the function definition is DEBUG only. ------------- PR: https://git.openjdk.org/jdk/pull/12607 From stuefe at openjdk.org Wed Mar 1 07:14:03 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 1 Mar 2023 07:14:03 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: References: Message-ID: On Sat, 25 Feb 2023 07:22:25 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan Friendly ping... need a second Reviewer. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From jsjolen at openjdk.org Wed Mar 1 08:55:09 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 1 Mar 2023 08:55:09 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> Message-ID: On Sat, 25 Feb 2023 02:36:36 GMT, David Holmes wrote: >> If we have a default value for the char* DCmdArgument we copy it into the `_value` field using `parse_value` to make a copy in C-heap. If we then parse an actual argument value, we replace the default but don't free it. The parse method needs to use realloc. >> >> Thanks to @jcking for spotting the cause. >> >> Testing: tiers 1-3 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update test coverage for the empty and null cases LGTM, thanks. ------------- Marked as reviewed by jsjolen (Committer). PR: https://git.openjdk.org/jdk/pull/12737 From alanb at openjdk.org Wed Mar 1 10:00:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 10:00:50 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v2] In-Reply-To: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: > This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. > > As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. > > The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. There are some minor adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. > > Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. Alan Bateman 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: - Clarify Thread CPU time seciton of spec - Merge - Fix minimal build - Fix minimal build - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12762/files - new: https://git.openjdk.org/jdk/pull/12762/files/c58765b3..7da35145 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=00-01 Stats: 3492 lines in 187 files changed: 2307 ins; 454 del; 731 mod Patch: https://git.openjdk.org/jdk/pull/12762.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12762/head:pull/12762 PR: https://git.openjdk.org/jdk/pull/12762 From eosterlund at openjdk.org Wed Mar 1 10:10:41 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 1 Mar 2023 10:10:41 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> Message-ID: On Sat, 25 Feb 2023 02:36:36 GMT, David Holmes wrote: >> If we have a default value for the char* DCmdArgument we copy it into the `_value` field using `parse_value` to make a copy in C-heap. If we then parse an actual argument value, we replace the default but don't free it. The parse method needs to use realloc. >> >> Thanks to @jcking for spotting the cause. >> >> Testing: tiers 1-3 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update test coverage for the empty and null cases The change looks good. Since I was asked to review in Coleen's absence, I feel like I just have to mention it's a bit weird that a template specialization of destroy_value causes different behaviour, and that I don't really like templates. But the change looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/12737 From alanb at openjdk.org Wed Mar 1 11:43:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 11:43:07 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v2] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Tue, 28 Feb 2023 21:06:19 GMT, Mandy Chung wrote: >> Alan Bateman 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: >> >> - Clarify Thread CPU time seciton of spec >> - Merge >> - Fix minimal build >> - Fix minimal build >> - Initial commit > > test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 258: > >> 256: long tid = Thread.currentThread().threadId(); >> 257: long cpuTime = bean.getThreadCpuTime(tid); >> 258: assertEquals(-1L, cpuTime); > > Am I correct that `getThreadCpuTime(tid)` returns -1 for the current thread is a virtual thread whereas `getCurrentThreadCpuTime` throws UOE in the current implementation? > > `getCurrentThreadCpuTime` is specified to be equivalent to calling `getThreadCpuTime(Thread.currentThread().threadId()`. We didn't get this quite right in JDK 19 but I think I've fixed all those issues now. So assuming the VM supports CPU time for all platform threads, it means: - isThreadCpuTimeEnabled and isCurrentThreadCpuTimeSupported will return true. - If getThreadCpuTime(long) is called with the thread ID of a virtual thread then -1 will be returned. - If getCurrentThreadCpuTime() is called from a virtual thread then -1 will be returned. I did another pass over the API docs, update the "Thread CPU time" section, so I hope it is clearer now. ------------- PR: https://git.openjdk.org/jdk/pull/12762 From coleenp at openjdk.org Wed Mar 1 12:38:13 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 1 Mar 2023 12:38:13 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> Message-ID: On Sat, 25 Feb 2023 02:36:36 GMT, David Holmes wrote: >> If we have a default value for the char* DCmdArgument we copy it into the `_value` field using `parse_value` to make a copy in C-heap. If we then parse an actual argument value, we replace the default but don't free it. The parse method needs to use realloc. >> >> Thanks to @jcking for spotting the cause. >> >> Testing: tiers 1-3 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update test coverage for the empty and null cases Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12737 From alanb at openjdk.org Wed Mar 1 12:39:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 12:39:52 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: > This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. > > As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. > > The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. There are some minor adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. > > Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Update isXXXThreadCpuTimeSupported descriptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12762/files - new: https://git.openjdk.org/jdk/pull/12762/files/7da35145..956a1e0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12762.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12762/head:pull/12762 PR: https://git.openjdk.org/jdk/pull/12762 From alanb at openjdk.org Wed Mar 1 12:39:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Mar 2023 12:39:55 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Tue, 28 Feb 2023 20:49:51 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Update isXXXThreadCpuTimeSupported descriptions > > src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 529: > >> 527: /** >> 528: * Tests if the Java virtual machine implementation supports CPU time >> 529: * measurement for any platform thread. > > This change can also apply in `@return` (line 538) Yes, this make sense although getting the word right for isCurrentThreadCpuTimeSupported is tricky because its about the caller of getCurrentThreadCpuTime/getCurrentThreadUserTime rather than the caller of isCurrentThreadCpuTimeSupported. Hopefully it is clearer now. ------------- PR: https://git.openjdk.org/jdk/pull/12762 From coleenp at openjdk.org Wed Mar 1 12:55:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 1 Mar 2023 12:55:06 GMT Subject: RFR: 8297936: Use reachabilityFence to manage liveness in ClassUnload tests [v2] In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 09:26:05 GMT, Afshin Zafari wrote: >> ### Description >> Instead of using static instances or using an object in print to keep it alive, `java.lang.ref.Reference.reachabilityFence(Object)` is used to keep an object alive and avoid class unloading. >> >> ### Tests >> linux-x64-debug, macosx-aarch64-debug, mach5 tier1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8297936: Use reachabilityFence to manage liveness in ClassUnload tests Looks good. Thank you for fixing this! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12552 From matsaave at openjdk.org Wed Mar 1 15:29:38 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 1 Mar 2023 15:29:38 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v8] In-Reply-To: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: > The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. > > Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Reverted some changed tests - Merge branch 'master' into cdsWarning_8292269 - Ioi patch and added error - Fixed a merge issue - Merge - More test fixes - Fixed tests - RequiresSharedSpaces now leads to VM exit later - Replaced fail_continue with log_info and log_warning - Merge branch 'master' into cdsWarning_8292269 - ... and 3 more: https://git.openjdk.org/jdk/compare/07e976ac...db1fe9d5 ------------- Changes: https://git.openjdk.org/jdk/pull/12419/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12419&range=07 Stats: 111 lines in 10 files changed: 14 ins; 44 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/12419.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12419/head:pull/12419 PR: https://git.openjdk.org/jdk/pull/12419 From jcking at openjdk.org Wed Mar 1 15:47:14 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 1 Mar 2023 15:47:14 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: References: Message-ID: On Sat, 25 Feb 2023 07:22:25 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan My main complaints with NMTPreInit are the CPU and memory overhead it imposes for those who are not using NMT. This change takes care of the first, but still has the latter. I wouldn't mind a slightly more complex approach which used closed-addressing to keep it flat and just re-sized as necessary. Allowing a cheap free on the whole thing when it is disabled. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From jcking at openjdk.org Wed Mar 1 15:56:25 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 1 Mar 2023 15:56:25 GMT Subject: Integrated: JDK-8303183: Memory leak in Arguments::init_shared_archive_paths In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 19:29:56 GMT, Justin King wrote: > Fix memory leak by freeing the memory returned by `Arguments::get_default_shared_archive_path()`. This pull request has now been integrated. Changeset: 4c985e52 Author: Justin King URL: https://git.openjdk.org/jdk/commit/4c985e527a4a03d5a78d85a145aa41c1843a3e22 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8303183: Memory leak in Arguments::init_shared_archive_paths Reviewed-by: jsjolen, ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12749 From jcking at openjdk.org Wed Mar 1 16:04:52 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 1 Mar 2023 16:04:52 GMT Subject: RFR: JDK-8303181: Memory leak in ClassLoaderExt::setup_app_search_path In-Reply-To: <5LqVHD0GpbLJXazzqRxJhqCYi_Zzjo6_kRx0jsC3Jt8=.d4b24f4f-aa6a-46df-8fc7-0878291b2c2d@github.com> References: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> <5LqVHD0GpbLJXazzqRxJhqCYi_Zzjo6_kRx0jsC3Jt8=.d4b24f4f-aa6a-46df-8fc7-0878291b2c2d@github.com> Message-ID: <6f5NKMFx2YZBadkVmmjSkH-Jt_FhHIKY8LA07Hczjcc=.4ea05a98-8346-485e-ac28-4ed3cd4da2ed@github.com> On Sun, 26 Feb 2023 22:31:23 GMT, David Holmes wrote: >> Fix memory leak by removing unnecessary `os::strdup` call. The string is passed as a const pointer to all functions. > > The problem here is that to reuse that string you have to know how/where it was originally allocated and know that it will remain safe to touch (assuming it is touched) for the lifetime of the code doing the touching. That might be true in this case but establishing that is a lot of effort, and ensuring it remains true is also then a problem. A strdup and subsequent free makes things a whole lot simpler IMO. @dholmes-ora Switched to `os::strdup_check_oom` with `os::free` per your suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/12748 From jcking at openjdk.org Wed Mar 1 16:04:50 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 1 Mar 2023 16:04:50 GMT Subject: RFR: JDK-8303181: Memory leak in ClassLoaderExt::setup_app_search_path [v2] In-Reply-To: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> References: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> Message-ID: > Fix memory leak by removing unnecessary `os::strdup` call. The string is passed as a const pointer to all functions. Justin King 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: - Switch to strdup_check_oom with free Signed-off-by: Justin King - Merge remote-tracking branch 'upstream/master' into classloaderext-leak - Remove unnecessary strdup Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12748/files - new: https://git.openjdk.org/jdk/pull/12748/files/d440b68f..78f04fa7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12748&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12748&range=00-01 Stats: 5499 lines in 272 files changed: 3377 ins; 1053 del; 1069 mod Patch: https://git.openjdk.org/jdk/pull/12748.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12748/head:pull/12748 PR: https://git.openjdk.org/jdk/pull/12748 From stuefe at openjdk.org Wed Mar 1 19:55:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 1 Mar 2023 19:55:14 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: References: Message-ID: <0CehKPeI727sNbOmIRmZ36TynxAfXosdKXE0RxznEWc=.6c931ae3-959c-429c-a648-078e4689ce90@github.com> On Wed, 1 Mar 2023 15:44:36 GMT, Justin King wrote: > My main complaints with NMTPreInit are the CPU and memory overhead it imposes for those who are not using NMT. This change takes care of the first, but still has the latter. Yes, sure, but let's keep perspective. We are talking about ~300..500 surviving allocations, which cost "leaked" LU entries of 7..12KB. Are we really worried about that? Even if we are this PR is already a step in the right direction since today NMTPreInit keeps the whole LU table alive. > I wouldn't mind a slightly more complex approach which used closed-addressing to keep it flat and just re-sized as necessary. Allowing a cheap free on the whole thing when it is disabled. Table resizing is costly, and may hurt startup. Entry removal for closed-addressing hashmaps is a pain to code, or well at least its complexish. Complex code does not get reviews :-( If the "leaked" entries really bug people, there are multiple ways out of it: 1) just iterating the LU table and freeing all entries - gain 12 KB at the expense of some CPU work. Maybe I should just do that since its 3 lines of code and avoids arguments. 2) chaining all LU entries together directly, at the cost of one additional next pointer, and walking that chain freeing all entries - saves having to walk the mostly sparse LU table 3) (my preferred solution) letting LU entries live in a heap structure (basically, arena like slab list with freelist atop of it) like we do e.g. in Metaspace. Then just delete the slab(s) in one go. (3) would be what I would do. But since I keep using this kind of data structure (metaspace, would make sense also for other hash table entry types, e.g. NMT), I would like to add it as generic container; but that raises other questions. So better for a follow up RFE. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From jcking at openjdk.org Wed Mar 1 20:10:08 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 1 Mar 2023 20:10:08 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: References: Message-ID: <1SVEHj0NcgUxKFtHqVF0vsrrzEvNGh-u9Wg9iajcyrQ=.ca724f2a-1b2e-43ec-9dc3-16fcb42a9a41@github.com> On Sat, 25 Feb 2023 07:22:25 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan Either of the 3 work for me, so long as we are not leaking. If we are intentionally leaking then I have to follow up with code to ignore leaks when built with LSan or most tests will fail. As far as leaked allocation cost, it really depends. Its almost never just the size of the request allocation. It entirely depends on where the malloc implementation placed the allocations. They could be all next to each other, which is ideal, or they could be fragmented. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From stuefe at openjdk.org Wed Mar 1 20:34:32 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 1 Mar 2023 20:34:32 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: <1SVEHj0NcgUxKFtHqVF0vsrrzEvNGh-u9Wg9iajcyrQ=.ca724f2a-1b2e-43ec-9dc3-16fcb42a9a41@github.com> References: <1SVEHj0NcgUxKFtHqVF0vsrrzEvNGh-u9Wg9iajcyrQ=.ca724f2a-1b2e-43ec-9dc3-16fcb42a9a41@github.com> Message-ID: <72vqiwKyZK9HbrDpRuZ2J_BOCCGJVT0pkOhTvogWt24=.c75d9059-82cd-4a3e-be3e-5788e04db9eb@github.com> On Wed, 1 Mar 2023 20:06:51 GMT, Justin King wrote: > Either of the 3 work for me, so long as we are not leaking. If we are intentionally leaking then I have to follow up with code to ignore leaks when built with LSan or most tests will fail. Okay, I'll do (1) then and earmark it for future improvement via (3) ------------- PR: https://git.openjdk.org/jdk/pull/12642 From lmesnik at openjdk.org Wed Mar 1 20:58:02 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 20:58:02 GMT Subject: RFR: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Message-ID: It is the 2nd attempt to fix [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. The first fix failed because it runs Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} with 0 as no timeout and not -1 as required. ------------- Commit messages: - the additional fix - Revert "8303421: [BACKOUT] 8303133: Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed." Changes: https://git.openjdk.org/jdk/pull/12815/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12815&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303486 Stats: 31 lines in 2 files changed: 18 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12815.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12815/head:pull/12815 PR: https://git.openjdk.org/jdk/pull/12815 From matsaave at openjdk.org Wed Mar 1 21:10:49 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 1 Mar 2023 21:10:49 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v3] In-Reply-To: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: > CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Moved check for exploded JDK ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12705/files - new: https://git.openjdk.org/jdk/pull/12705/files/34d34d9b..1b396d92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12705&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12705&range=01-02 Stats: 11 lines in 1 file changed: 5 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12705.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12705/head:pull/12705 PR: https://git.openjdk.org/jdk/pull/12705 From matsaave at openjdk.org Wed Mar 1 21:38:12 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 1 Mar 2023 21:38:12 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v2] In-Reply-To: <-jZ453fBN1vWZzsw3k1V838Ma79TPyHicV23MC2Mr8I=.91123cad-5381-4fe1-bf0e-3ab5a48a097e@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> <-jZ453fBN1vWZzsw3k1V838Ma79TPyHicV23MC2Mr8I=.91123cad-5381-4fe1-bf0e-3ab5a48a097e@github.com> Message-ID: <8f3tmysWFvae4frIvPZOQg1LoX5nXWyQzAqz8ZFHM0c=.127fb8ec-ac87-403b-9330-378c61939737@github.com> On Tue, 28 Feb 2023 00:46:32 GMT, Ioi Lam wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced condition with assert > > src/hotspot/share/runtime/arguments.cpp line 2927: > >> 2925: UseSharedSpaces = false; >> 2926: RequireSharedSpaces = false; >> 2927: } > > I think you should call `no_shared_spaces()` instead. That way, the VM will print an error message and exit if `-Xshare:on` is specified. Adding `no_shared_spaces()` here makes sense but it results in a duplicate output. I will move this check up to the caller of this method to avoid redundant logs. ------------- PR: https://git.openjdk.org/jdk/pull/12705 From mchung at openjdk.org Wed Mar 1 21:41:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Mar 2023 21:41:05 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: <8oxX7u8M2132OZEhwIskF2O3ACV2EF6mjnoJwvUF3wA=.5ea494c5-ee73-4495-b135-b690f2eae463@github.com> On Wed, 1 Mar 2023 12:39:52 GMT, Alan Bateman wrote: >> This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. >> >> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. >> >> The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. >> >> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Update isXXXThreadCpuTimeSupported descriptions Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12762 From mchung at openjdk.org Wed Mar 1 21:41:07 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Mar 2023 21:41:07 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Wed, 1 Mar 2023 11:40:26 GMT, Alan Bateman wrote: >> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 258: >> >>> 256: long tid = Thread.currentThread().threadId(); >>> 257: long cpuTime = bean.getThreadCpuTime(tid); >>> 258: assertEquals(-1L, cpuTime); >> >> Am I correct that `getThreadCpuTime(tid)` returns -1 for the current thread is a virtual thread whereas `getCurrentThreadCpuTime` throws UOE in the current implementation? >> >> `getCurrentThreadCpuTime` is specified to be equivalent to calling `getThreadCpuTime(Thread.currentThread().threadId()`. > > We didn't get this quite right in JDK 19 but I think I've fixed all those issues now. So assuming the VM supports CPU time for all platform threads, it means: > > - isThreadCpuTimeEnabled and isCurrentThreadCpuTimeSupported will return true. > - If getThreadCpuTime(long) is called with the thread ID of a virtual thread then -1 will be returned. > - If getCurrentThreadCpuTime() is called from a virtual thread then -1 will be returned. > > I did another pass over the API docs, update the "Thread CPU time" section, so I hope it is clearer now. This looks better. I see `testGetCurrentThreadCpuTime` and `testGetCurrentThreadUserTime` test cases fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12762 From dholmes at openjdk.org Wed Mar 1 21:48:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 21:48:20 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> Message-ID: On Wed, 1 Mar 2023 10:08:12 GMT, Erik ?sterlund wrote: > I feel like I just have to mention it's a bit weird that a template specialization of destroy_value causes different behaviour @fisk I don't follow your comment. The issue is missing free - hence use of realloc. But thanks for the review :) ------------- PR: https://git.openjdk.org/jdk/pull/12737 From dholmes at openjdk.org Wed Mar 1 21:48:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 21:48:22 GMT Subject: RFR: 8303070: Memory leak in DCmdArgument::parse_value [v4] In-Reply-To: <7pxGZNzeJsZjubOz-x7tle8naI-r4ugDLkGBKUE8Yjo=.efe9c5ee-0e64-4e35-8bf0-f6775b9374f4@github.com> References: <-ZaUYFVHwrAXmAaqU3UElLG8z4TUi1myQpyeRr-5qqo=.c7391c03-c233-4074-beba-f8c36509983f@github.com> <7pxGZNzeJsZjubOz-x7tle8naI-r4ugDLkGBKUE8Yjo=.efe9c5ee-0e64-4e35-8bf0-f6775b9374f4@github.com> Message-ID: On Wed, 1 Mar 2023 03:04:38 GMT, Frederic Parain wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test coverage for the empty and null cases > > Marked as reviewed by fparain (Committer). Thanks for (re-) reviews @fparain , @coleenp and @jdksjolen ! ------------- PR: https://git.openjdk.org/jdk/pull/12737 From dholmes at openjdk.org Wed Mar 1 21:48:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 21:48:24 GMT Subject: Integrated: 8303070: Memory leak in DCmdArgument::parse_value In-Reply-To: References: Message-ID: <-a0HcobZMiw8rlA2pXFUbPwpOzeLk3_z0Ewi1PDwuFg=.bdd52bce-cb80-4f3d-a2e6-2decbf7130f9@github.com> On Fri, 24 Feb 2023 00:26:13 GMT, David Holmes wrote: > If we have a default value for the char* DCmdArgument we copy it into the `_value` field using `parse_value` to make a copy in C-heap. If we then parse an actual argument value, we replace the default but don't free it. The parse method needs to use realloc. > > Thanks to @jcking for spotting the cause. > > Testing: tiers 1-3 > > Thanks. This pull request has now been integrated. Changeset: 6e19387f Author: David Holmes URL: https://git.openjdk.org/jdk/commit/6e19387f29944aa9d5c82bf0ece3abf0ca53b39c Stats: 28 lines in 2 files changed: 14 ins; 10 del; 4 mod 8303070: Memory leak in DCmdArgument::parse_value Reviewed-by: fparain, jcking, jsjolen, eosterlund, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12737 From mchung at openjdk.org Wed Mar 1 21:50:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Mar 2023 21:50:17 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Wed, 1 Mar 2023 12:39:52 GMT, Alan Bateman wrote: >> This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. >> >> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. >> >> The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. >> >> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Update isXXXThreadCpuTimeSupported descriptions src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 479: > 477: * if the thread of the specified ID exists, the thread is alive, > 478: * and CPU time measurement is enabled; {@code -1} if not enabled > 479: * or the specified ID is a virtual thread It should be "{@code -1} if not enabled or the specified ID is a virtual thread or the thread does not exist or not alive." Would this be simpler: * @return the total CPU time for a thread of the specified ID * if the thread of the specified ID is a platform thread, the thread is alive, * and CPU time measurement is enabled; {@code -1} otherwise. I'm fine with either way. Same comment for `getThreadUserTime(long)` ------------- PR: https://git.openjdk.org/jdk/pull/12762 From stuefe at openjdk.org Wed Mar 1 21:55:56 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 1 Mar 2023 21:55:56 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v3] In-Reply-To: References: Message-ID: <00OzA3vIk_cMeyO8xAIEHl0SLKclcAxX24XLfRdVIsg=.4b9d7aff-3e5b-43d7-9694-a267e4eb065e@github.com> > NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. > > I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. > > NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. > > That has two advantages: > - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. > - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. > > ----- > > I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). > > But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. > > (Please note that I enter vacation and won't be able to react promptly to reviews.) > > --- > > Tests: > - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) > - GHAs ongoing Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Delete LU entries after VM init; fix test for NMT=off case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12642/files - new: https://git.openjdk.org/jdk/pull/12642/files/d2971f6e..13c0a7e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12642&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12642&range=01-02 Stats: 60 lines in 4 files changed: 14 ins; 1 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/12642.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12642/head:pull/12642 PR: https://git.openjdk.org/jdk/pull/12642 From stuefe at openjdk.org Wed Mar 1 21:55:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 1 Mar 2023 21:55:58 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2] In-Reply-To: References: Message-ID: On Sat, 25 Feb 2023 07:22:25 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan Okay, LU entries get deleted now. Also fixed test for NMT=off that derailed because it was assuming the table still existed unconditionally in post-init. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From lmesnik at openjdk.org Wed Mar 1 22:16:19 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Mar 2023 22:16:19 GMT Subject: RFR: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: <0eyqbd8WB3uBRXQmilqJ3k55DinDymm8fb6iMqhtQZE=.cca6d23d-1a35-494d-a2aa-42c3e6ab91a4@github.com> On Wed, 1 Mar 2023 00:03:50 GMT, Mikhailo Seledtsov wrote: >> Some old nsk code is removed, and logging is moved to the based class. >> No functional changes. > > Looks good to me. thanks @mseledts, can I have one more review pls? ------------- PR: https://git.openjdk.org/jdk/pull/12777 From matsaave at openjdk.org Wed Mar 1 22:18:12 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 1 Mar 2023 22:18:12 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v9] In-Reply-To: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: > The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. > > Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Reverted Xshare option in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12419/files - new: https://git.openjdk.org/jdk/pull/12419/files/db1fe9d5..4887a142 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12419&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12419&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12419.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12419/head:pull/12419 PR: https://git.openjdk.org/jdk/pull/12419 From ccheung at openjdk.org Wed Mar 1 22:30:26 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 1 Mar 2023 22:30:26 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v3] In-Reply-To: References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: On Wed, 1 Mar 2023 21:10:49 GMT, Matias Saavedra Silva wrote: >> CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Moved check for exploded JDK Updates look good. Thanks. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12705 From dholmes at openjdk.org Wed Mar 1 22:42:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Mar 2023 22:42:24 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v9] In-Reply-To: References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: On Wed, 1 Mar 2023 22:18:12 GMT, Matias Saavedra Silva wrote: >> The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. >> >> Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Reverted Xshare option in test Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12419 From ccheung at openjdk.org Wed Mar 1 23:31:00 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 1 Mar 2023 23:31:00 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode [v2] In-Reply-To: References: Message-ID: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> > Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. > Otherwise, JVM crashes with the following message in the hs err log: > `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: make the _methods array writable during dump time for old classes with jsr bytecode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12752/files - new: https://git.openjdk.org/jdk/pull/12752/files/6a8b5251..ecea6558 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12752&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12752&range=00-01 Stats: 40 lines in 3 files changed: 30 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12752/head:pull/12752 PR: https://git.openjdk.org/jdk/pull/12752 From ccheung at openjdk.org Wed Mar 1 23:31:03 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 1 Mar 2023 23:31:03 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 23:28:14 GMT, Calvin Cheung wrote: > Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. > Otherwise, JVM crashes with the following message in the hs err log: > `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` > > Passed tiers 1 - 4 testing. I have pushed a commit. The fix is make the _methods array writable during dump time for "old" classes with the jsr byte code. Ran tiers 1 - 3 testing successfully. ------------- PR: https://git.openjdk.org/jdk/pull/12752 From dholmes at openjdk.org Thu Mar 2 01:10:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 01:10:16 GMT Subject: RFR: JDK-8303181: Memory leak in ClassLoaderExt::setup_app_search_path [v2] In-Reply-To: References: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> Message-ID: On Wed, 1 Mar 2023 16:04:50 GMT, Justin King wrote: >> Fix memory leak by removing unnecessary `os::strdup` call. The string is passed as a const pointer to all functions. > > Justin King 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: > > - Switch to strdup_check_oom with free > > Signed-off-by: Justin King > - Merge remote-tracking branch 'upstream/master' into classloaderext-leak > - Remove unnecessary strdup > > Signed-off-by: Justin King Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12748 From dholmes at openjdk.org Thu Mar 2 01:20:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 01:20:11 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode [v2] In-Reply-To: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> References: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> Message-ID: On Wed, 1 Mar 2023 23:31:00 GMT, Calvin Cheung wrote: >> Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. >> Otherwise, JVM crashes with the following message in the hs err log: >> `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > make the _methods array writable during dump time for old classes with jsr bytecode I'm not familiar enough with CDS to review this in detail sorry. The approach sounds reasonable. Thanks ------------- PR: https://git.openjdk.org/jdk/pull/12752 From dholmes at openjdk.org Thu Mar 2 06:23:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 06:23:11 GMT Subject: RFR: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: On Wed, 1 Mar 2023 20:50:38 GMT, Leonid Mesnik wrote: > It is the 2nd attempt to fix > [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. > > The first fix failed because it runs > Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} > with 0 as no timeout and not -1 as required. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12815 From stuefe at openjdk.org Thu Mar 2 07:22:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 07:22:49 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: Message-ID: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> > NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. > > I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. > > NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. > > That has two advantages: > - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. > - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. > > ----- > > I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). > > But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. > > (Please note that I enter vacation and won't be able to react promptly to reviews.) > > --- > > Tests: > - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) > - GHAs ongoing 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 four additional commits since the last revision: - Merge branch 'master' into make-nmt-preinit-cheaper-for-nmt-off - Delete LU entries after VM init; fix test for NMT=off case - feedback johan - make-nmt-preinit-cheaper-for-nmt-off ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12642/files - new: https://git.openjdk.org/jdk/pull/12642/files/13c0a7e2..4ab49b4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12642&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12642&range=02-03 Stats: 13929 lines in 611 files changed: 9169 ins; 2610 del; 2150 mod Patch: https://git.openjdk.org/jdk/pull/12642.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12642/head:pull/12642 PR: https://git.openjdk.org/jdk/pull/12642 From alanb at openjdk.org Thu Mar 2 08:18:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 08:18:03 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v4] In-Reply-To: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: > This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. > > As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. > > The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. > > Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Tweak javadoc to avoid listing too many conditions in @return description - Merge - Update isXXXThreadCpuTimeSupported descriptions - Clarify Thread CPU time seciton of spec - Merge - Fix minimal build - Fix minimal build - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12762/files - new: https://git.openjdk.org/jdk/pull/12762/files/956a1e0d..dd212cdb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12762&range=02-03 Stats: 1256 lines in 50 files changed: 999 ins; 156 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/12762.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12762/head:pull/12762 PR: https://git.openjdk.org/jdk/pull/12762 From alanb at openjdk.org Thu Mar 2 08:18:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 08:18:05 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v3] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Wed, 1 Mar 2023 21:46:54 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Update isXXXThreadCpuTimeSupported descriptions > > src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 479: > >> 477: * if the thread of the specified ID exists, the thread is alive, >> 478: * and CPU time measurement is enabled; {@code -1} if not enabled >> 479: * or the specified ID is a virtual thread > > It should be "{@code -1} if not enabled or the specified ID is a virtual thread or the thread does not exist or not alive." > > Would this be simpler: > > > * @return the total CPU time for a thread of the specified ID > * if the thread of the specified ID is a platform thread, the thread is alive, > * and CPU time measurement is enabled; {@code -1} otherwise. > > > I'm fine with either way. Same comment for `getThreadUserTime(long)` That is a bit better as it avoids needing to list conditions for the "otherwise" case. I've update these methods to use that style and also updated the CSR. ------------- PR: https://git.openjdk.org/jdk/pull/12762 From stuefe at openjdk.org Thu Mar 2 10:49:09 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 10:49:09 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 07:22:49 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > 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 four additional commits since the last revision: > > - Merge branch 'master' into make-nmt-preinit-cheaper-for-nmt-off > - Delete LU entries after VM init; fix test for NMT=off case > - feedback johan > - make-nmt-preinit-cheaper-for-nmt-off x86 test error unrelated ------------- PR: https://git.openjdk.org/jdk/pull/12642 From adinn at openjdk.org Thu Mar 2 12:15:17 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Mar 2023 12:15:17 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 07:22:49 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > 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 four additional commits since the last revision: > > - Merge branch 'master' into make-nmt-preinit-cheaper-for-nmt-off > - Delete LU entries after VM init; fix test for NMT=off case > - feedback johan > - make-nmt-preinit-cheaper-for-nmt-off Looks good to go. Hi Thomas, I fully agree with the arguments you provided in https://bugs.openjdk.org/browse/JDK-8299196 for retaining NMT pre init tracking. So, I think this change is a necessary improvement. However, I also agree with Justin that the cost of the leaks will be a case where the sum is greater than the parts due to fragmentation. It may well hurt more than is apparent. So, one of the three options you suggested to clear the redundant table entries should be implemented. I'd be happy to see that as a follow-up patch since: - this code is ready to ship and improves the status quo - a follow-up patch can investigate which is the best of the 3 options No nits as far as the code is concerned. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12642 From duke at openjdk.org Thu Mar 2 12:24:11 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 12:24:11 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Message-ID: ### Description The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. ### Test local and mach5 tier1 ------------- Commit messages: - 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Changes: https://git.openjdk.org/jdk/pull/12827/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301622 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12827.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12827/head:pull/12827 PR: https://git.openjdk.org/jdk/pull/12827 From stuefe at openjdk.org Thu Mar 2 13:24:29 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 13:24:29 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 12:12:18 GMT, Andrew Dinn wrote: > Hi Thomas, > > I fully agree with the arguments you provided in https://bugs.openjdk.org/browse/JDK-8299196 for retaining NMT pre init tracking. So, I think this change is a necessary improvement. > > However, I also agree with Justin that the cost of the leaks will be a case where the sum is greater than the parts due to fragmentation. It may well hurt more than is apparent. So, one of the three options you suggested to clear the redundant table entries should be implemented. I'd be happy to see that as a follow-up patch since: > > * this code is ready to ship and improves the status quo > > * a follow-up patch can investigate which is the best of the 3 options > > > No nits as far as the code is concerned. Hi @adinn, thanks a lot for the review! The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From stuefe at openjdk.org Thu Mar 2 13:24:30 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 13:24:30 GMT Subject: Integrated: JDK-8302820: Remove costs for NMTPreInit when NMT is off In-Reply-To: References: Message-ID: On Sun, 19 Feb 2023 10:02:39 GMT, Thomas Stuefe wrote: > NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. > > I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. > > NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. > > That has two advantages: > - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. > - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. > > ----- > > I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). > > But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. > > (Please note that I enter vacation and won't be able to react promptly to reviews.) > > --- > > Tests: > - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) > - GHAs ongoing This pull request has now been integrated. Changeset: c9afd55e Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/c9afd55ed6e0d60b43f87fbae66af3559424e51f Stats: 252 lines in 5 files changed: 114 ins; 48 del; 90 mod 8302820: Remove costs for NMTPreInit when NMT is off Reviewed-by: jsjolen, adinn ------------- PR: https://git.openjdk.org/jdk/pull/12642 From jsjolen at openjdk.org Thu Mar 2 13:28:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 2 Mar 2023 13:28:11 GMT Subject: RFR: 8204550: NMT: RegionIterator does not need to keep _current_size Message-ID: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Hi, This is just a small cleanup where an unnecessary class variable is removed. Quoting the issue: >class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). Please consider, thanks. ------------- Commit messages: - Remove _current_size Changes: https://git.openjdk.org/jdk/pull/12828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8204550 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12828.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12828/head:pull/12828 PR: https://git.openjdk.org/jdk/pull/12828 From jsjolen at openjdk.org Thu Mar 2 14:13:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 2 Mar 2023 14:13:00 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT Message-ID: Hi, This PR attempts to enforce the convention that: 1. Public `os` functions report to NMT 2. `pd_` prefixed functions do not report to NMT 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8255414-separate-pd-os - Do not use unadorned os function in pd_-adorned function Changes: https://git.openjdk.org/jdk/pull/12832/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255414 Stats: 46 lines in 8 files changed: 15 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/12832.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12832/head:pull/12832 PR: https://git.openjdk.org/jdk/pull/12832 From alanb at openjdk.org Thu Mar 2 14:16:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 14:16:06 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: Message-ID: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> On Thu, 2 Mar 2023 12:15:21 GMT, Afshin Zafari wrote: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 test/lib/jdk/test/lib/process/ProcessTools.java line 827: > 825: > 826: public void uncaughtException(Thread t, Throwable e) { > 827: if (e instanceof Error && t.getState() == State.TERMINATED) { Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? ------------- PR: https://git.openjdk.org/jdk/pull/12827 From adinn at openjdk.org Thu Mar 2 14:34:11 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 2 Mar 2023 14:34:11 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 13:19:27 GMT, Thomas Stuefe wrote: > The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From stuefe at openjdk.org Thu Mar 2 15:01:59 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 15:01:59 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 14:30:23 GMT, Andrew Dinn wrote: > > The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. > > Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. Me too. I'll do it in a separate RFE. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From gziemski at openjdk.org Thu Mar 2 15:19:28 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 2 Mar 2023 15:19:28 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 07:22:49 GMT, Thomas Stuefe wrote: >> NMTPreInit has been brought into question lately (see [JDK-8299196](https://bugs.openjdk.org/browse/JDK-8299196) and [JDK-8301811](https://bugs.openjdk.org/browse/JDK-8301811)). The points of contention were costs paid when NMT is off, and complexity. >> >> I believe NMTPreInit is vital (for reasons why see discussion under [8299196](https://bugs.openjdk.org/browse/JDK-8299196) ), and removing it would be a severe mistake. So let's address the cost problem. >> >> NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. Granted, this cost is already pretty low since the load factor of that table is small. But we can avoid that lookup completely by allocating pre-init blocks without malloc headers. >> >> That has two advantages: >> - costs for NMTPreInit for NMT=off are practically nil now: all that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to do that anyway to see if NMT is switched on. That cost is not going away unless we get rid of NMT itself. >> - We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory. >> >> ----- >> >> I have done my best to come up with a good compromise between complexity, startup speed, and memory consumption. With a bit more complexity, penalties to startup speed could be even more reduced (e.g. by shepherding preallocation headers into their arena). >> >> But I'm between a rock and a hard place here: more complexity increases the chance of "its too complex, let's just remove it", which is a tiny bit stressful tbh. And the one point I feel strongly about is that getting rid of NMTPreInit would be a grave mistake. I also don't think this code needs more optimization. >> >> (Please note that I enter vacation and won't be able to react promptly to reviews.) >> >> --- >> >> Tests: >> - Manually tested linux x64 and x86 (gtests with all NMT permutations; runtime/NMT) >> - GHAs ongoing > > 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 four additional commits since the last revision: > > - Merge branch 'master' into make-nmt-preinit-cheaper-for-nmt-off > - Delete LU entries after VM init; fix test for NMT=off case > - feedback johan > - make-nmt-preinit-cheaper-for-nmt-off I know that this has been already pushed, but I will still take a look and file issues if I come across something worthwhile... ------------- PR: https://git.openjdk.org/jdk/pull/12642 From jcking at openjdk.org Thu Mar 2 16:33:47 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 2 Mar 2023 16:33:47 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 14:58:32 GMT, Thomas Stuefe wrote: >>> The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. >> >> Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. > >> > The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. >> >> Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. > > Me too. I'll do it in a separate RFE. Thank you @tstuefe for addressing this. I also have come around to keeping nmtpreinit, and like this path forward. Much appreciated! ------------- PR: https://git.openjdk.org/jdk/pull/12642 From duke at openjdk.org Thu Mar 2 17:31:18 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 17:31:18 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> Message-ID: On Thu, 2 Mar 2023 14:13:10 GMT, Alan Bateman wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > test/lib/jdk/test/lib/process/ProcessTools.java line 827: > >> 825: >> 826: public void uncaughtException(Thread t, Throwable e) { >> 827: if (e instanceof Error && t.getState() == State.TERMINATED) { > > Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? ------------- PR: https://git.openjdk.org/jdk/pull/12827 From ccheung at openjdk.org Thu Mar 2 17:34:21 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 2 Mar 2023 17:34:21 GMT Subject: RFR: JDK-8303181: Memory leak in ClassLoaderExt::setup_app_search_path [v2] In-Reply-To: References: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> Message-ID: <2okZa0AsJRjy_-Jjps8agQWc9fW5EttF0HZPtCueYD8=.afe80b06-3fec-4642-aa8e-1605300974c6@github.com> On Wed, 1 Mar 2023 16:04:50 GMT, Justin King wrote: >> Fix memory leak by removing unnecessary `os::strdup` call. The string is passed as a const pointer to all functions. > > Justin King 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: > > - Switch to strdup_check_oom with free > > Signed-off-by: Justin King > - Merge remote-tracking branch 'upstream/master' into classloaderext-leak > - Remove unnecessary strdup > > Signed-off-by: Justin King Updates look good. Thanks. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12748 From alanb at openjdk.org Thu Mar 2 17:38:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 17:38:15 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> Message-ID: <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> On Thu, 2 Mar 2023 17:27:59 GMT, Afshin Zafari wrote: >> test/lib/jdk/test/lib/process/ProcessTools.java line 827: >> >>> 825: >>> 826: public void uncaughtException(Thread t, Throwable e) { >>> 827: if (e instanceof Error && t.getState() == State.TERMINATED) { >> >> Dropping the check for ThreadDeath is fine but checking the thread state is puzzling. When a Thread completes with an uncaught exception/error then the UHE is called from the thread before it terminates so it's state won't be TERMINATED. Is there more going on here that the UHE is called with an already terminated Thread? > > I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. > Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? I think it can be removed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From duke at openjdk.org Thu Mar 2 17:43:54 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 17:43:54 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12827/files - new: https://git.openjdk.org/jdk/pull/12827/files/c03cd8f8..473b7cff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12827&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12827.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12827/head:pull/12827 PR: https://git.openjdk.org/jdk/pull/12827 From alanb at openjdk.org Thu Mar 2 17:43:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Mar 2023 17:43:56 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: <9q8GRBZhZsv0zX7w1QxkPySdB2M2KD6vw4oLwrL41QA=.8ea4568b-8bf4-428d-bd81-82641087e252@github.com> On Thu, 2 Mar 2023 17:39:10 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning test/lib/jdk/test/lib/process/ProcessTools.java line 35: > 33: import java.io.OutputStream; > 34: import java.io.PrintStream; > 35: import java.lang.Thread.State; This is no longer needed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From mchung at openjdk.org Thu Mar 2 17:53:07 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Mar 2023 17:53:07 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v4] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Thu, 2 Mar 2023 08:18:03 GMT, Alan Bateman wrote: >> This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. >> >> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. >> >> The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. >> >> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Tweak javadoc to avoid listing too many conditions in @return description > - Merge > - Update isXXXThreadCpuTimeSupported descriptions > - Clarify Thread CPU time seciton of spec > - Merge > - Fix minimal build > - Fix minimal build > - Initial commit Marked as reviewed by mchung (Reviewer). Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/12762 From stuefe at openjdk.org Thu Mar 2 17:56:23 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 2 Mar 2023 17:56:23 GMT Subject: RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v4] In-Reply-To: References: <-ZOfFoSdBG_93UPSF_Diu_iAWz2yo6PS8MW3mZ0gGiQ=.28c69b34-1f9d-4577-8294-f1c7ef60c0a3@github.com> Message-ID: On Thu, 2 Mar 2023 14:58:32 GMT, Thomas Stuefe wrote: >>> The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. >> >> Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. > >> > The latest version of my patch from tonight already frees the LU table nodes (see nmtPreinit.cpp 104ff). It was tested successfully tonight and in addition I ran x64 and x86 fastdebug release tests manually. >> >> Ah ok, yes, I see the destructor implements option 1. I still like the idea of pursuing option 3 via a generic container if the cost of writing and maintaining it can be justified by other uses. > > Me too. I'll do it in a separate RFE. > Thank you @tstuefe for addressing this. I also have come around to keeping nmtpreinit, and like this path forward. Much appreciated! Thank you @jcking. I came around to your argument of avoiding leaks. Finding unintentional leaks is bad enough without having to deal with intentional leaks. ------------- PR: https://git.openjdk.org/jdk/pull/12642 From dholmes at openjdk.org Thu Mar 2 21:55:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 21:55:23 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: <9Q_RyRESdJDvP7DjrfkJKNPOgsPmu_jcFFgisaRwDZk=.f1a80314-4aca-478f-ac88-c525fcab2ac0@github.com> On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. Sorry Johan but I don't agree with this approach. src/hotspot/os/bsd/os_bsd.cpp line 1638: > 1636: bool os::pd_create_stack_guard_pages(char* addr, size_t size) { > 1637: return os::pd_commit_memory(addr, size, !ExecMem); > 1638: } Sorry but this is wrong IMO. A pd_ function should in general still call the os:: version of other functions because it doesn't know what that might do in addition to eventually calling the pd_ variant. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12832 From dholmes at openjdk.org Thu Mar 2 21:59:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 21:59:24 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. I think the functions that do the actual work should report to NMT. That way if you have a call chain: os::foo() -> os::pd_foo() -> os::bar() -> os::pd_bar(); then the reporting only happens in `os::pd_bar()`. ------------- PR: https://git.openjdk.org/jdk/pull/12832 From dholmes at openjdk.org Thu Mar 2 22:07:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 2 Mar 2023 22:07:29 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:43:54 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning The check for ThreadDeath was to basically ignore the uncaught exception from Thread.stop(). Such an exception is no longer possible so the check can just be deleted. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12827 From duke at openjdk.org Thu Mar 2 22:12:07 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 2 Mar 2023 22:12:07 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> References: <6DJKnl1KHpUHIvIfdjn3KYAKJhvu9iLRhlz0CVL8DlA=.3324e840-6812-4020-b93b-9aea9d2442f1@github.com> <471GonMmx1x-bXzHkzjWs3w3MNuOuf54zYzZXSpMUxk=.ae71e576-4796-412f-bd65-51f1ecf5b457@github.com> Message-ID: On Thu, 2 Mar 2023 17:35:35 GMT, Alan Bateman wrote: >> I assumed the `ThreadDeath` was there to catch `Thread.stop()` calls and just ignore them. So, I wanted to keep this functionality. >> Can we remove using `ThreadDeath` relying on that `Thread.stop()` is also deprecated? > > I think it can be removed. Removed. ------------- PR: https://git.openjdk.org/jdk/pull/12827 From dholmes at openjdk.org Fri Mar 3 05:07:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Mar 2023 05:07:16 GMT Subject: RFR: 8303151: DCmd framework cleanups Message-ID: Whilst working on the DCmd code I noticed two items that could be cleaned up: 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. Testing: tiers 1-3 Thanks ------------- Commit messages: - 8303151: DCmd framework cleanups Changes: https://git.openjdk.org/jdk/pull/12847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12847&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303151 Stats: 13 lines in 3 files changed: 1 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12847/head:pull/12847 PR: https://git.openjdk.org/jdk/pull/12847 From yyang at openjdk.org Fri Mar 3 06:20:10 2023 From: yyang at openjdk.org (Yi Yang) Date: Fri, 3 Mar 2023 06:20:10 GMT Subject: RFR: 8303151: DCmd framework cleanups In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 04:59:44 GMT, David Holmes wrote: > Whilst working on the DCmd code I noticed two items that could be cleaned up: > > 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. > > 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. > > Testing: tiers 1-3 > > Thanks Is it possible to remove DCmdRegistrant too? Maybe `void DCmdFactory::register_dcmds` or `void register_dcmds` ------------- PR: https://git.openjdk.org/jdk/pull/12847 From alanb at openjdk.org Fri Mar 3 07:04:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Mar 2023 07:04:05 GMT Subject: RFR: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning [v2] In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 17:43:54 GMT, Afshin Zafari wrote: >> ### Description >> The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. >> >> >> ### Test >> local and mach5 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12827 From fyang at openjdk.org Fri Mar 3 09:22:12 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 3 Mar 2023 09:22:12 GMT Subject: RFR: 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at Message-ID: Hi, Please review this trivial change removing some obsolete code comments in os::pd_attempt_reserve_memory_at. These comments became obsolete after JDK-8224871 which removes the retry loop to mmap random memory. ------------- Commit messages: - 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at Changes: https://git.openjdk.org/jdk/pull/12849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12849&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303562 Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12849/head:pull/12849 PR: https://git.openjdk.org/jdk/pull/12849 From stuefe at openjdk.org Fri Mar 3 10:01:06 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 3 Mar 2023 10:01:06 GMT Subject: RFR: 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 09:14:01 GMT, Fei Yang wrote: > Hi, Please review this trivial change removing some obsolete code comments in os::pd_attempt_reserve_memory_at. These comments became obsolete after JDK-8224871 which removes the retry loop to mmap random memory in the same function. Good and trivial. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12849 From duke at openjdk.org Fri Mar 3 13:20:29 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 3 Mar 2023 13:20:29 GMT Subject: Integrated: 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 12:15:21 GMT, Afshin Zafari wrote: > ### Description > The use of `ThreadDeath` is replaced with checking the exception be of type `Error` and the thread is `TERMINATED`. > > > ### Test > local and mach5 tier1 This pull request has now been integrated. Changeset: ff364c19 Author: Afshin Zafari Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/ff364c1906f078c13e121a43e60606caff5781e7 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod 8301622: ProcessTools.java compilation gets ThreadDeath deprecation warning Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/12827 From jsjolen at openjdk.org Fri Mar 3 13:31:14 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 3 Mar 2023 13:31:14 GMT Subject: RFR: 8303151: DCmd framework cleanups In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 04:59:44 GMT, David Holmes wrote: > Whilst working on the DCmd code I noticed two items that could be cleaned up: > > 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. > > 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. > > Testing: tiers 1-3 > > Thanks LGTM, thanks for the clean up. ------------- Marked as reviewed by jsjolen (Committer). PR: https://git.openjdk.org/jdk/pull/12847 From duke at openjdk.org Fri Mar 3 16:48:08 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 3 Mar 2023 16:48:08 GMT Subject: Integrated: 8297936: Use reachabilityFence to manage liveness in ClassUnload tests In-Reply-To: References: Message-ID: On Tue, 14 Feb 2023 09:02:09 GMT, Afshin Zafari wrote: > ### Description > Instead of using static instances or using an object in print to keep it alive, `java.lang.ref.Reference.reachabilityFence(Object)` is used to keep an object alive and avoid class unloading. > > ### Tests > linux-x64-debug, macosx-aarch64-debug, mach5 tier1-5 This pull request has now been integrated. Changeset: 5085bd5f Author: Afshin Zafari Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/5085bd5f05ca70e08c6764ed208d574c556b6c57 Stats: 23 lines in 3 files changed: 9 ins; 5 del; 9 mod 8297936: Use reachabilityFence to manage liveness in ClassUnload tests Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12552 From pchilanomate at openjdk.org Fri Mar 3 17:33:10 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 3 Mar 2023 17:33:10 GMT Subject: RFR: 8303242: ThreadMXBean issues with virtual threads [v4] In-Reply-To: References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Thu, 2 Mar 2023 08:18:03 GMT, Alan Bateman wrote: >> This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. >> >> As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. >> >> The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. >> >> Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Tweak javadoc to avoid listing too many conditions in @return description > - Merge > - Update isXXXThreadCpuTimeSupported descriptions > - Clarify Thread CPU time seciton of spec > - Merge > - Fix minimal build > - Fix minimal build > - Initial commit Looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk/pull/12762 From matsaave at openjdk.org Fri Mar 3 18:10:14 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 3 Mar 2023 18:10:14 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v10] In-Reply-To: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: > The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. > > Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Added early exit for one case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12419/files - new: https://git.openjdk.org/jdk/pull/12419/files/4887a142..8d7c1d4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12419&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12419&range=08-09 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12419.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12419/head:pull/12419 PR: https://git.openjdk.org/jdk/pull/12419 From matsaave at openjdk.org Fri Mar 3 18:10:18 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 3 Mar 2023 18:10:18 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v9] In-Reply-To: References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: On Wed, 1 Mar 2023 22:18:12 GMT, Matias Saavedra Silva wrote: >> The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. >> >> Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Reverted Xshare option in test One test was failing due to an unexpected output. This PR moves the vm exit to a later stage for most cases, but in order to preserve the pre-change behavior, an early exit was added for a specific case. ------------- PR: https://git.openjdk.org/jdk/pull/12419 From jcking at openjdk.org Fri Mar 3 18:11:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 3 Mar 2023 18:11:41 GMT Subject: Integrated: JDK-8303181: Memory leak in ClassLoaderExt::setup_app_search_path In-Reply-To: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> References: <8GCBgEioqXRCdzeODQ2ZIMWYFrHwFXISS0_Y4kP570M=.2208faab-d06b-4499-9c30-60d1491dadfa@github.com> Message-ID: On Fri, 24 Feb 2023 19:23:36 GMT, Justin King wrote: > Fix memory leak by removing unnecessary `os::strdup` call. The string is passed as a const pointer to all functions. This pull request has now been integrated. Changeset: 40c5edfc Author: Justin King URL: https://git.openjdk.org/jdk/commit/40c5edfcc4ad98af435d2edf3dd40f20f24fca46 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8303181: Memory leak in ClassLoaderExt::setup_app_search_path Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12748 From ccheung at openjdk.org Fri Mar 3 18:25:14 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 3 Mar 2023 18:25:14 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v10] In-Reply-To: References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: <6Z_bhvyAWDakY8Zr4PNX1pInONmDwFYS-1GZGn8l7aA=.4328e1ba-e175-4daa-89cc-3b7a944b6438@github.com> On Fri, 3 Mar 2023 18:10:14 GMT, Matias Saavedra Silva wrote: >> The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. >> >> Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Added early exit for one case Updates look good. Just one nit. src/hotspot/share/cds/metaspaceShared.cpp line 914: > 912: log_info(cds)("Core region alignment: " SIZE_FORMAT, static_mapinfo->core_region_alignment()); > 913: dynamic_mapinfo = open_dynamic_archive(); > 914: Please remove this added blank line. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12419 From matsaave at openjdk.org Fri Mar 3 18:42:19 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 3 Mar 2023 18:42:19 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v10] In-Reply-To: <6Z_bhvyAWDakY8Zr4PNX1pInONmDwFYS-1GZGn8l7aA=.4328e1ba-e175-4daa-89cc-3b7a944b6438@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> <6Z_bhvyAWDakY8Zr4PNX1pInONmDwFYS-1GZGn8l7aA=.4328e1ba-e175-4daa-89cc-3b7a944b6438@github.com> Message-ID: <1IAnJrxfs9pdxW9hiqg2hvijZjZLotktRi7mH5JjYG0=.49ddde91-9c0e-4e0d-b18a-b033d236245d@github.com> On Fri, 3 Mar 2023 18:21:21 GMT, Calvin Cheung wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Added early exit for one case > > src/hotspot/share/cds/metaspaceShared.cpp line 914: > >> 912: log_info(cds)("Core region alignment: " SIZE_FORMAT, static_mapinfo->core_region_alignment()); >> 913: dynamic_mapinfo = open_dynamic_archive(); >> 914: > > Please remove this added blank line. This blank line was present before my change, I just restored it. ------------- PR: https://git.openjdk.org/jdk/pull/12419 From matsaave at openjdk.org Fri Mar 3 18:46:20 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 3 Mar 2023 18:46:20 GMT Subject: RFR: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging [v10] In-Reply-To: <6Z_bhvyAWDakY8Zr4PNX1pInONmDwFYS-1GZGn8l7aA=.4328e1ba-e175-4daa-89cc-3b7a944b6438@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> <6Z_bhvyAWDakY8Zr4PNX1pInONmDwFYS-1GZGn8l7aA=.4328e1ba-e175-4daa-89cc-3b7a944b6438@github.com> Message-ID: On Fri, 3 Mar 2023 18:22:12 GMT, Calvin Cheung wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Added early exit for one case > > Updates look good. Just one nit. Thank you for the reviews and feedback @calvinccheung , @dholmes-ora , and @iklam ! ------------- PR: https://git.openjdk.org/jdk/pull/12419 From fparain at openjdk.org Fri Mar 3 18:55:04 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 3 Mar 2023 18:55:04 GMT Subject: RFR: 8300654: Remove JVMFlag::flag_error_str as it is unused In-Reply-To: References: Message-ID: On Sat, 18 Feb 2023 15:35:35 GMT, Afshin Zafari wrote: > The function definition and declaration are removed. > > ### Test > mach5 tiers 1-5 Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/12636 From matsaave at openjdk.org Fri Mar 3 19:03:29 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 3 Mar 2023 19:03:29 GMT Subject: Integrated: 8292269: Replace FileMapInfo::fail_continue() with Unified Logging In-Reply-To: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> References: <4iW_osWb83psn_Xru5jmd1GlRZEen25cVuOozeatSfQ=.09bb5752-7d22-441d-a03a-780962d13ab9@github.com> Message-ID: On Fri, 3 Feb 2023 21:02:01 GMT, Matias Saavedra Silva wrote: > The current logging method FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped and has variable behavior depending on the -Xshare mode. Logging calls are divided primarily between the "warning" and "info" channels, where the "info" channel was used to reduce the number of printed logs for expected and normal failures. > > Logging will now shift toward Unified Logging, so `fail_continue()` will be replaced with `log_info(cds)` and `log_warning(cds)`. Some genuine failures will be logged to the warning channel for better visibility. Upon actual failures, the VM will exit at MetaspaceShared::initialize_runtime_shared_and_meta_spaces() unless it is otherwise necessary. Relevant tests are updated to accommodate this change. Verified with tier1-4 tests This pull request has now been integrated. Changeset: cd4b88d0 Author: Matias Saavedra Silva Committer: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/cd4b88d0d25958d3b5de2982233bc540ba5a4e3b Stats: 113 lines in 9 files changed: 18 ins; 42 del; 53 mod 8292269: Replace FileMapInfo::fail_continue() with Unified Logging Reviewed-by: iklam, dholmes, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/12419 From jcking at openjdk.org Fri Mar 3 19:49:22 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 3 Mar 2023 19:49:22 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests Message-ID: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Fix memory leaks identified while running Metaspace gtests. ------------- Commit messages: - Fix various memory leaks in Metaspace tests Changes: https://git.openjdk.org/jdk/pull/12865/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303605 Stats: 23 lines in 4 files changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12865/head:pull/12865 PR: https://git.openjdk.org/jdk/pull/12865 From jcking at openjdk.org Fri Mar 3 20:02:09 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 3 Mar 2023 20:02:09 GMT Subject: RFR: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg Message-ID: Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. ------------- Commit messages: - Memory leaks in Arguments::parse_each_vm_init_arg Changes: https://git.openjdk.org/jdk/pull/12867/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12867&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303606 Stats: 17 lines in 2 files changed: 10 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12867.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12867/head:pull/12867 PR: https://git.openjdk.org/jdk/pull/12867 From jcking at openjdk.org Fri Mar 3 22:31:54 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 3 Mar 2023 22:31:54 GMT Subject: RFR: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg [v2] In-Reply-To: References: Message-ID: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> > Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add missing const_cast Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12867/files - new: https://git.openjdk.org/jdk/pull/12867/files/822d9bd2..167c4b5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12867&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12867&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12867.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12867/head:pull/12867 PR: https://git.openjdk.org/jdk/pull/12867 From kvn at openjdk.org Sat Mar 4 02:00:11 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 4 Mar 2023 02:00:11 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:16:08 GMT, Vladimir Kozlov wrote: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. GHA failure on linux-x86 in test compiler/vectorization/runner/LoopRangeStrideTest.java is due to [JDK-8303105](https://bugs.openjdk.org/browse/JDK-8303105) ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Sat Mar 4 02:13:10 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 4 Mar 2023 02:13:10 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:16:08 GMT, Vladimir Kozlov wrote: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. GHA failure on linux-x86 in test java/foreign/callarranger/TestMacOsAArch64CallArranger.java most likely due to [JDK-8303516](https://bugs.openjdk.org/browse/JDK-8303516). I did not have the fix when submitted PR. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From alanb at openjdk.org Sat Mar 4 07:37:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Mar 2023 07:37:23 GMT Subject: Integrated: 8303242: ThreadMXBean issues with virtual threads In-Reply-To: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> References: <_qWp1Z5LY9I2q6Wy9Zdyt-m8V9D_502fyM4X5iUJi_0=.5083a667-5c61-4bc4-9961-98d689b80b7a@github.com> Message-ID: On Mon, 27 Feb 2023 12:23:09 GMT, Alan Bateman wrote: > This PR covers a number of issues with j.l.management.ThreadMXBean, and the JDK-specific extension c.s.management.ThreadMXBean, when there are virtual threads in use. > > As background, ThreadMXBean was re-specified in Java 19 to support the monitoring and management of platform threads. It does not support virtual threads as their potential number, and the need to find a thread by id, does not make sense for this API. At the same time, JDK 19 introduced an alternative implementation of virtual threads for Zero and ports without continuations support in the VM. This alternative implementation of virtual threads means a JavaThread per virtual thread and so requires filtering to ensure that the API behaves as specified. For the initial implementation, the filtering was done in the ThreadMXBean implementation. That works for most functions but not for getThreadXXXTime(long[]) and getThreadAllocatedBytes(long[]) where the filtering needs to be pushed down to the management code. > > The changes in this PR move the filtering to the management functions (jmm_XXX) so they only return information about platform threads. It also fixes ThreadMXBean.getCurrentThreadCpuTime and getCurrentThreadUserTime to not throw UOE when CPU time measurement from a platform thread is supported. There are some small adjustments to the API docs (see linked CSR). Test coverage is expanded as we didn't include tests for c.s.management.ThreadMXBean with virtual threads in JDK 19. > > Testing tier1-3 (jdk_management test group is in test/jdk/:tier3), plus sanity checking that --with-jvm-variants=minimal builds as some of this code is not compiled in with minimal VM builds. This pull request has now been integrated. Changeset: 629a9053 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/629a9053f072a3d8406b923f8fa8ab7056a1ab8d Stats: 531 lines in 8 files changed: 285 ins; 138 del; 108 mod 8303242: ThreadMXBean issues with virtual threads Reviewed-by: mchung, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/12762 From dholmes at openjdk.org Sat Mar 4 08:50:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 4 Mar 2023 08:50:44 GMT Subject: RFR: 8303151: DCmd framework cleanups [v2] In-Reply-To: References: Message-ID: > Whilst working on the DCmd code I noticed two items that could be cleaned up: > > 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. > > 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. > > Testing: tiers 1-3 > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12847/files - new: https://git.openjdk.org/jdk/pull/12847/files/4e8d6b56..7f29eba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12847&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12847&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12847/head:pull/12847 PR: https://git.openjdk.org/jdk/pull/12847 From dholmes at openjdk.org Sat Mar 4 08:50:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 4 Mar 2023 08:50:44 GMT Subject: RFR: 8303151: DCmd framework cleanups In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 06:17:14 GMT, Yi Yang wrote: > Is it possible to remove DCmdRegistrant too? Thanks for looking at this. Yes this would be possible I think. Not sure why the `DCmdRegistrant` class was considered necessary ... probably to support alternative implementations of `register_dcmd_ext()`. I think it could reside in the DCmd class. ------------- PR: https://git.openjdk.org/jdk/pull/12847 From dholmes at openjdk.org Sat Mar 4 08:50:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 4 Mar 2023 08:50:44 GMT Subject: RFR: 8303151: DCmd framework cleanups [v2] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 13:27:58 GMT, Johan Sj?len wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment > > LGTM, thanks for the clean up. Thanks for the review @jdksjolen ! ------------- PR: https://git.openjdk.org/jdk/pull/12847 From stuefe at openjdk.org Sat Mar 4 09:16:11 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 4 Mar 2023 09:16:11 GMT Subject: RFR: 8303151: DCmd framework cleanups [v2] In-Reply-To: References: Message-ID: On Sat, 4 Mar 2023 08:50:44 GMT, David Holmes wrote: >> Whilst working on the DCmd code I noticed two items that could be cleaned up: >> >> 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. >> >> 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. >> >> Testing: tiers 1-3 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12847 From stuefe at openjdk.org Sat Mar 4 09:36:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 4 Mar 2023 09:36:04 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests In-Reply-To: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Fri, 3 Mar 2023 19:40:40 GMT, Justin King wrote: > Fix memory leaks identified while running Metaspace gtests. Mostly good, small nits remain. test/hotspot/gtest/metaspace/test_freeblocks.cpp line 103: > 101: DEBUG_ONLY(_freeblocks.verify();) > 102: } > 103: } Can you reshape this a bit pls: let deallocate_top return bool (false if nothing removed) and do void deallocate_all() { while (!deallocate_top()); } test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 506: > 504: > 505: VirtualSpaceNode* node = VirtualSpaceNode::create_node(word_size, &cl, &sres, &scomm); > 506: please remove whitespace change test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 543: > 541: DEBUG_ONLY(node->verify_locked();) > 542: > 543: delete node; Can you please add an ASSERT after the delete to test that sres and scomm are 0? ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12865 From stuefe at openjdk.org Sat Mar 4 09:36:05 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 4 Mar 2023 09:36:05 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Sat, 4 Mar 2023 09:29:03 GMT, Thomas Stuefe wrote: >> Fix memory leaks identified while running Metaspace gtests. > > test/hotspot/gtest/metaspace/test_freeblocks.cpp line 103: > >> 101: DEBUG_ONLY(_freeblocks.verify();) >> 102: } >> 103: } > > Can you reshape this a bit pls: let deallocate_top return bool (false if nothing removed) and do > > void deallocate_all() { > while (!deallocate_top()); > } I'm a bit concerned about runtime. Does the runtime for these tests increase, since the verification on every deallocation is a bit overboard? ------------- PR: https://git.openjdk.org/jdk/pull/12865 From jwaters at openjdk.org Sat Mar 4 19:01:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 4 Mar 2023 19:01:15 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v15] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Sat, 4 Feb 2023 15:05:06 GMT, Julian Waters wrote: >> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)). >> >> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used. >> >> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right >> >> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446)) > > Julian Waters 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 15 additional commits since the last revision: > > - Merge branch 'openjdk:master' into alignas > - alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 5 more: https://git.openjdk.org/jdk/compare/9971522f...a621bb62 :( ------------- PR: https://git.openjdk.org/jdk/pull/11431 From dholmes at openjdk.org Sun Mar 5 05:46:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 5 Mar 2023 05:46:37 GMT Subject: RFR: 8303151: DCmd framework cleanups [v3] In-Reply-To: References: Message-ID: <6wxCXp_ubcVulb9p7XWSmHB7fwTswyY2SALaKs_zyjs=.c9a28950-968a-4c52-9a86-ac33ba08e80b@github.com> > Whilst working on the DCmd code I noticed two items that could be cleaned up: > > 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. > > 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. > > Testing: tiers 1-3 > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Relocate regoster_dcmds to DCmd class and get rid of DCmdRegistrat class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12847/files - new: https://git.openjdk.org/jdk/pull/12847/files/7f29eba9..1b1afce5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12847&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12847&range=01-02 Stats: 19 lines in 3 files changed: 5 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12847/head:pull/12847 PR: https://git.openjdk.org/jdk/pull/12847 From dholmes at openjdk.org Sun Mar 5 05:46:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 5 Mar 2023 05:46:37 GMT Subject: RFR: 8303151: DCmd framework cleanups [v2] In-Reply-To: References: Message-ID: On Sat, 4 Mar 2023 09:12:54 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment > > +1 Thanks for the review @tstuefe Re-running test builds after latest adjustment. ------------- PR: https://git.openjdk.org/jdk/pull/12847 From dholmes at openjdk.org Sun Mar 5 22:47:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 5 Mar 2023 22:47:14 GMT Subject: RFR: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Mon, 27 Feb 2023 20:18:21 GMT, Leonid Mesnik wrote: > Some old nsk code is removed, and logging is moved to the based class. > No functional changes. I would say there are functional changes here: - you got rid of thread termination using System.exit (which is good, but a change) - you got rid of the ability to process arguments (why?) - you hard wired the timeout and logging options ?? ------------- PR: https://git.openjdk.org/jdk/pull/12777 From lmesnik at openjdk.org Sun Mar 5 23:22:21 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 5 Mar 2023 23:22:21 GMT Subject: RFR: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 20:18:21 GMT, Leonid Mesnik wrote: > Some old nsk code is removed, and logging is moved to the based class. > No functional changes. The arguments processing might have been useful when vmTestbase was a separate product. It was the only possibility to vary the parameters of tests without re-building the whole vmTestbase. However, now this ability is not needed. It is easy just to change the source code if needed to update wait time or logger. The tests don't change them by themself. So, I think this code just complicates test reading. ------------- PR: https://git.openjdk.org/jdk/pull/12777 From fyang at openjdk.org Mon Mar 6 00:37:17 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 6 Mar 2023 00:37:17 GMT Subject: RFR: 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 09:58:11 GMT, Thomas Stuefe wrote: > Good and trivial. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/12849 From fyang at openjdk.org Mon Mar 6 00:37:18 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 6 Mar 2023 00:37:18 GMT Subject: Integrated: 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 09:14:01 GMT, Fei Yang wrote: > Hi, Please review this trivial change removing some obsolete code comments in os::pd_attempt_reserve_memory_at. These comments became obsolete after JDK-8224871 which removes the retry loop to mmap random memory in the same function. This pull request has now been integrated. Changeset: 148900c2 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/148900c2dcc50d6c4672af3224c94b430dfb372b Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod 8303562: Remove obsolete comments in os::pd_attempt_reserve_memory_at Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/12849 From dholmes at openjdk.org Mon Mar 6 01:11:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 6 Mar 2023 01:11:12 GMT Subject: RFR: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 20:18:21 GMT, Leonid Mesnik wrote: > Some old nsk code is removed, and logging is moved to the based class. > No functional changes. The flexibilty to change options without having to edit and rebuild still seems convenient to me. But if you and @mseledts are okay with getting rid of this then okay. Approved. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12777 From yyang at openjdk.org Mon Mar 6 02:09:15 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 6 Mar 2023 02:09:15 GMT Subject: RFR: 8303151: DCmd framework cleanups [v3] In-Reply-To: <6wxCXp_ubcVulb9p7XWSmHB7fwTswyY2SALaKs_zyjs=.c9a28950-968a-4c52-9a86-ac33ba08e80b@github.com> References: <6wxCXp_ubcVulb9p7XWSmHB7fwTswyY2SALaKs_zyjs=.c9a28950-968a-4c52-9a86-ac33ba08e80b@github.com> Message-ID: On Sun, 5 Mar 2023 05:46:37 GMT, David Holmes wrote: >> Whilst working on the DCmd code I noticed two items that could be cleaned up: >> >> 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. >> >> 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. >> >> Testing: tiers 1-3 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Relocate regoster_dcmds to DCmd class and get rid of DCmdRegistrat class Thanks for doing this. Looks good to me. ------------- Marked as reviewed by yyang (Committer). PR: https://git.openjdk.org/jdk/pull/12847 From duke at openjdk.org Mon Mar 6 12:49:14 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 6 Mar 2023 12:49:14 GMT Subject: Integrated: 8300654: Remove JVMFlag::flag_error_str as it is unused In-Reply-To: References: Message-ID: On Sat, 18 Feb 2023 15:35:35 GMT, Afshin Zafari wrote: > The function definition and declaration are removed. > > ### Test > mach5 tiers 1-5 This pull request has now been integrated. Changeset: 8e201452 Author: Afshin Zafari Committer: Frederic Parain URL: https://git.openjdk.org/jdk/commit/8e2014527ead67ce33627a49223b8269a94f3102 Stats: 17 lines in 2 files changed: 0 ins; 16 del; 1 mod 8300654: Remove JVMFlag::flag_error_str as it is unused Reviewed-by: dholmes, fparain ------------- PR: https://git.openjdk.org/jdk/pull/12636 From jsjolen at openjdk.org Mon Mar 6 13:01:07 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 6 Mar 2023 13:01:07 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. Hi David, thanks for the input! I'm not sure which approach is the correct one, so getting this PR out for review was important as a discussion starter. > Sorry but this is wrong IMO. A pd_ function should in general still call the os:: version of other functions because it doesn't know what that might do in addition to eventually calling the pd_ variant. I see your point, but right now the only difference is NMT code. Previously it was just inconsistent. > I think the functions that do the actual work should report to NMT. That way if you have a call chain: > > ``` > os::foo() -> os::pd_foo() -> os::bar() -> os::pd_bar(); > ``` > > then the reporting only happens in `os::pd_bar()`. What I dislike about this is that a reader will always go through `os::foo()` to know whether it reports to NMT or not. With this solution, the reader needs to go through the entire call chain. It seems to me like the situation might become more complex when a new codepath is added that depends on two `pd_` calls in sequence (might lead to incorrect accounting). Being 'shallow' with NMT makes sense in this context. ------------- PR: https://git.openjdk.org/jdk/pull/12832 From stuefe at openjdk.org Mon Mar 6 14:02:26 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 6 Mar 2023 14:02:26 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. No time atm to review, but I like the direction of this patch. This has been inconsistent for a long time and occasionally tricky to get right. I think NMT-hooking functions are few enough that the rule "os::xxx calls NMT, then does platform stuff" is enforceable. ------------- PR: https://git.openjdk.org/jdk/pull/12832 From lmesnik at openjdk.org Mon Mar 6 15:35:13 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 6 Mar 2023 15:35:13 GMT Subject: Integrated: 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. In-Reply-To: References: Message-ID: <3qbZUBW7mR3lxnLEcB3eMXMaHvafWHFDxdFf76GkQhU=.f8a0490b-4044-443c-8366-e549e1004c67@github.com> On Wed, 1 Mar 2023 20:50:38 GMT, Leonid Mesnik wrote: > It is the 2nd attempt to fix > [JDK-8303133](https://bugs.openjdk.org/browse/JDK-8303133) Update ProcessTools.startProcess(...) to exit early if the process exit before linePredicate is printed. > > The first fix failed because it runs > Utils.waitForCondition(BooleanSupplier condition, long timeout, long sleepTime) { ..} > with 0 as no timeout and not -1 as required. This pull request has now been integrated. Changeset: ae8730fd Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ae8730fd62b382564cda8749763b939aa2939225 Stats: 30 lines in 2 files changed: 18 ins; 3 del; 9 mod 8303486: [REDO] Update ProcessTools.startProcess(...) to exit early if process exit before linePredicate is printed. Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12815 From lmesnik at openjdk.org Mon Mar 6 15:37:22 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 6 Mar 2023 15:37:22 GMT Subject: Integrated: 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 20:18:21 GMT, Leonid Mesnik wrote: > Some old nsk code is removed, and logging is moved to the based class. > No functional changes. This pull request has now been integrated. Changeset: 877ab659 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/877ab659b94a275683db72a39a4699d3847b11f3 Stats: 598 lines in 16 files changed: 14 ins; 507 del; 77 mod 8303264: Refactor nsk/stress/strace to extract shared and remove redundant code Reviewed-by: mseledtsov, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12777 From stuefe at openjdk.org Mon Mar 6 16:08:13 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 6 Mar 2023 16:08:13 GMT Subject: RFR: 8204550: NMT: RegionIterator does not need to keep _current_size In-Reply-To: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> References: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Message-ID: On Thu, 2 Mar 2023 13:20:06 GMT, Johan Sj?len wrote: > Hi, > > This is just a small cleanup where an unnecessary class variable is removed. > > Quoting the issue: > >>class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). > > Please consider, thanks. Thanks :-) ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12828 From jsjolen at openjdk.org Mon Mar 6 16:08:18 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 6 Mar 2023 16:08:18 GMT Subject: RFR: 8204550: NMT: RegionIterator does not need to keep _current_size In-Reply-To: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> References: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Message-ID: On Thu, 2 Mar 2023 13:20:06 GMT, Johan Sj?len wrote: > Hi, > > This is just a small cleanup where an unnecessary class variable is removed. > > Quoting the issue: > >>class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). > > Please consider, thanks. Hi @tstuefe, are you interested in this PR? It's an old one that you reported that was closed and now re-opened and fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12828 From kvn at openjdk.org Mon Mar 6 16:09:13 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 16:09:13 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Message-ID: Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. Tested tier1-5, Xcomp, stress ------------- Commit messages: - Remove ConvF2HFNode::Identity(). Updated tests - Copyright year update - Check float16 instructions support on platforms for C1 - Update Copyright year. Add missing UnlockDiagnosticVMOptions flag in new test - Implement Aarch64 and RiscV parts, remove 32-bit x86 runtime stub - Merge branch 'master' into 8302976 - 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Changes: https://git.openjdk.org/jdk/pull/12869/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302976 Stats: 1432 lines in 48 files changed: 1284 ins; 97 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Mon Mar 6 16:09:14 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 16:09:14 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress GHA failure on linux-x86 in test compiler/vectorization/runner/LoopRangeStrideTest.java is due to [JDK-8303105](https://bugs.openjdk.org/browse/JDK-8303105) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From jcking at openjdk.org Mon Mar 6 16:30:08 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Mar 2023 16:30:08 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v2] In-Reply-To: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: > Fix memory leaks identified while running Metaspace gtests. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update based on review Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12865/files - new: https://git.openjdk.org/jdk/pull/12865/files/744abfa0..b4b96a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=00-01 Stats: 14 lines in 2 files changed: 4 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12865/head:pull/12865 PR: https://git.openjdk.org/jdk/pull/12865 From jcking at openjdk.org Mon Mar 6 16:30:11 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Mar 2023 16:30:11 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v2] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: <4GZ7HAkw2KlEqiiAyJ0GfAUaLrBoKai-uPicgHcKzMA=.609390e6-b974-4081-8f50-700b17b9914b@github.com> On Sat, 4 Mar 2023 09:29:33 GMT, Thomas Stuefe wrote: >> test/hotspot/gtest/metaspace/test_freeblocks.cpp line 103: >> >>> 101: DEBUG_ONLY(_freeblocks.verify();) >>> 102: } >>> 103: } >> >> Can you reshape this a bit pls: let deallocate_top return bool (false if nothing removed) and do >> >> void deallocate_all() { >> while (!deallocate_top()); >> } > > I'm a bit concerned about runtime. Does the runtime for these tests increase, since the verification on every deallocation is a bit overboard? It's not noticeable. Restructed the code. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From jcking at openjdk.org Mon Mar 6 16:30:16 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Mar 2023 16:30:16 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v2] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Sat, 4 Mar 2023 09:32:18 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on review >> >> Signed-off-by: Justin King > > test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 543: > >> 541: DEBUG_ONLY(node->verify_locked();) >> 542: >> 543: delete node; > > Can you please add an ASSERT after the delete to test that sres and scomm are 0? Done. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From gziemski at openjdk.org Mon Mar 6 16:39:58 2023 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 6 Mar 2023 16:39:58 GMT Subject: RFR: 8204550: NMT: RegionIterator does not need to keep _current_size In-Reply-To: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> References: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Message-ID: On Thu, 2 Mar 2023 13:20:06 GMT, Johan Sj?len wrote: > Hi, > > This is just a small cleanup where an unnecessary class variable is removed. > > Quoting the issue: > >>class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). > > Please consider, thanks. Nice cleanup, looks good to me. ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.org/jdk/pull/12828 From jcking at openjdk.org Mon Mar 6 21:01:02 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 6 Mar 2023 21:01:02 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v3] In-Reply-To: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: <8WXkT33DKx9CjId6BOZ-d_HnbQRB5Slr95U4bWE0qEs=.7d380458-f5fb-4df6-8137-6a69c3e31be0@github.com> > Fix memory leaks identified while running Metaspace gtests. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix sign comparision mismatch Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12865/files - new: https://git.openjdk.org/jdk/pull/12865/files/b4b96a2e..57df305e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12865/head:pull/12865 PR: https://git.openjdk.org/jdk/pull/12865 From dholmes at openjdk.org Mon Mar 6 22:00:01 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 6 Mar 2023 22:00:01 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads Message-ID: To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. Testing: tiers 1-3 as a sanity test There's no way to write a regression test for this. Thanks. ------------- Commit messages: - 8303624: JavaThread logic doesn't allow for the use of the java.lang.Thread.FieldHolder in all cases Changes: https://git.openjdk.org/jdk/pull/12892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303624 Stats: 61 lines in 3 files changed: 24 ins; 21 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12892.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12892/head:pull/12892 PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Mon Mar 6 23:20:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 6 Mar 2023 23:20:13 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. I don't like to see NMT being a reason to define special "rules" for how to string together shared and pd code. AFAICS if you do the accounting at the top-level (as currently done for os::reserve_memory) then this PR trying to solve the problem that: os -> pd -> os does double accounting. So you are changing it to: os -> pd -> pd but in general to me that risks under-accounting. So there is no general rule to apply here, each case has to be examined to see if it would double-account (and if so change it), or under-account (and if so change it). A general rule that platform specific code always calls the os::xxx version of a method is a generally good rule to have (and we have made a lot of changes in the past few years to have the pd code call back to the potentially shared os code). To do otherwise requires detailed knowledge of what the os version does and that it is okay to by-pass it; but if the os version is later changed then it might become wrong to bypass it. ------------- PR: https://git.openjdk.org/jdk/pull/12832 From kvn at openjdk.org Mon Mar 6 23:57:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 6 Mar 2023 23:57:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress @fyang, please help to verify that new tests passed on RISC-V with these changes and review these changes. Thanks! I tested x86 (64- and 32-bit) and AArch64. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 00:22:15 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 00:22:15 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 23:54:44 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > @fyang, please help to verify that new tests passed on RISC-V with these changes and review these changes. Thanks! > > I tested x86 (64- and 32-bit) and AArch64. @vnkozlov Thanks a lot for taking this up. Is the following in the PR description still true: "Replaced SharedRuntime::f2hf() and hf2f() C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic." >From the PR it looks to me that for x86_64 you have the changes in place for SharedRuntime and the same result is produced across SharedRuntime, interpreter, c1, and c2. For x86 32-bit also things are consistent across. Only the SharedRuntime optimization doesnt happen for x86 32bit as StubRoutines::hf2f() and StubRoutines::f2hf() are set as null. The fallback is handled correctly in interpreter, c1, and c2. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 00:51:12 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 00:51:12 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 00:19:03 GMT, Sandhya Viswanathan wrote: > For x86 32-bit also things are consistent across. Only the SharedRuntime optimization doesnt happen for x86 32bit as StubRoutines::hf2f() and StubRoutines::f2hf() are set as null. The fallback is handled correctly in interpreter, c1, and c2. Correct, it is consistent. Only optimization to calculate constant value during compile time is skipped. C2 will generate HW instruction for `ConvF2HF` node as if its input was not constant. That is it. It is possible to add similar Stub routines for AArch64 and RISC-V to be called from C2 but I am not expert in those platforms so I skipped them. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 00:55:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 00:55:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Note, I removed `ConvF2HFNode::Identity()` optimization because tests show that it produces different NaN results due to skipped conversion. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Tue Mar 7 01:04:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 01:04:05 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > There's no way to write a regression test for this. Clarification: there's no way to write a general regression test for accessing the fieldHolder fields via JVMTI while the thread is attaching. The original failure scenario of the Thread constructor throwing an exception could potentially be testable. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From sviswanathan at openjdk.org Tue Mar 7 01:24:19 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:24:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress src/hotspot/cpu/x86/macroAssembler_x86.hpp line 199: > 197: void flt_to_flt16(Register dst, XMMRegister src, XMMRegister tmp) { > 198: // Instruction requires different XMM registers > 199: vcvtps2ph(tmp, src, 0x04, Assembler::AVX_128bit); vcvtps2ph can have source and destination as same. Did you mean to say here in the comment that "Instruction requires XMM register as destination"? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3928: > 3926: } > 3927: > 3928: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { We could check for VM_Version::supports_float16() here instead. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: > 3929: // For results consistency both intrinsics should be enabled. > 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && > 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { Should this also check for InlineIntrinsics? src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 346: > 344: } > 345: // For AVX CPUs only. f16c support is disabled if UseAVX == 0. > 346: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { We could check for VM_Version::supports_float16() here instead. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 01:29:13 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:29:13 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 00:52:37 GMT, Vladimir Kozlov wrote: > Note, I removed `ConvF2HFNode::Identity()` optimization because tests show that it produces different NaN results due to skipped conversion. Yes, removing the Identity optimization is correct. It doesn't hold for NaN inputs. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 01:29:16 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 01:29:16 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Other than the minor comments above, the x86 side changes look good to me. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From cslucas at openjdk.org Tue Mar 7 01:51:13 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 7 Mar 2023 01:51:13 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges Message-ID: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges? The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently. The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information. I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure. ------------- Commit messages: - Add support for rematerializing scalar replaced objects participating in allocation merges Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287061 Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From kvn at openjdk.org Tue Mar 7 02:07:21 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:07:21 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Thank you for review @sviswa7. I will address you comments. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 02:07:26 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:07:26 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:04:00 GMT, Sandhya Viswanathan wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > src/hotspot/cpu/x86/macroAssembler_x86.hpp line 199: > >> 197: void flt_to_flt16(Register dst, XMMRegister src, XMMRegister tmp) { >> 198: // Instruction requires different XMM registers >> 199: vcvtps2ph(tmp, src, 0x04, Assembler::AVX_128bit); > > vcvtps2ph can have source and destination as same. Did you mean to say here in the comment that "Instruction requires XMM register as destination"? `flt_to_flt16` is used in `x86.ad` instruction which requires preserving `src` register. I did not want to add an other macroassembler instruction for src->src case. I will add this to this comment. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3928: > >> 3926: } >> 3927: >> 3928: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { > > We could check for VM_Version::supports_float16() here instead. Yes. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: > >> 3929: // For results consistency both intrinsics should be enabled. >> 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && >> 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { > > Should this also check for InlineIntrinsics? `vmIntrinsics::disabled_by_jvm_flags()` checks `InlineIntrinsics`. See `vmIntrinsics.cpp` changes. > src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 346: > >> 344: } >> 345: // For AVX CPUs only. f16c support is disabled if UseAVX == 0. >> 346: if (VM_Version::supports_f16c() || VM_Version::supports_avx512vl()) { > > We could check for VM_Version::supports_float16() here instead. Yes. And I need to remove `!InlineIntrinsics` check at line 340. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From sviswanathan at openjdk.org Tue Mar 7 02:45:15 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 02:45:15 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:59:25 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3931: >> >>> 3929: // For results consistency both intrinsics should be enabled. >>> 3930: if (vmIntrinsics::is_intrinsic_available(vmIntrinsics::_float16ToFloat) && >>> 3931: vmIntrinsics::is_intrinsic_available(vmIntrinsics::_floatToFloat16)) { >> >> Should this also check for InlineIntrinsics? > > `vmIntrinsics::disabled_by_jvm_flags()` checks `InlineIntrinsics`. See `vmIntrinsics.cpp` changes. Yes you are right. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 02:53:48 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 02:53:48 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: References: Message-ID: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/2eb47bf5..9302d4bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=00-01 Stats: 86 lines in 8 files changed: 15 ins; 24 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 03:03:07 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 03:03:07 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 01:26:44 GMT, Sandhya Viswanathan wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Other than the minor comments above, the x86 side changes look good to me. @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Tue Mar 7 03:18:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 03:18:15 GMT Subject: RFR: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg [v2] In-Reply-To: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> References: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> Message-ID: On Fri, 3 Mar 2023 22:31:54 GMT, Justin King wrote: >> Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add missing const_cast > > Signed-off-by: Justin King Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12867 From minqi at openjdk.org Tue Mar 7 04:49:15 2023 From: minqi at openjdk.org (Yumin Qi) Date: Tue, 7 Mar 2023 04:49:15 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode [v2] In-Reply-To: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> References: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> Message-ID: <8jurYzTunx8_HRvhXAcQNgLPECDL5buIY6CaQGRsWNE=.9c77d680-a250-4257-a8fe-c0b56c7733f2@github.com> On Wed, 1 Mar 2023 23:31:00 GMT, Calvin Cheung wrote: >> Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. >> Otherwise, JVM crashes with the following message in the hs err log: >> `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > make the _methods array writable during dump time for old classes with jsr bytecode LGTM. We know after 49.0 (java 5), jsr will not be generated, so this should not be a problem for dynamic dumping too. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.org/jdk/pull/12752 From jsjolen at openjdk.org Tue Mar 7 07:28:22 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 7 Mar 2023 07:28:22 GMT Subject: RFR: 8204550: NMT: RegionIterator does not need to keep _current_size In-Reply-To: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> References: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Message-ID: On Thu, 2 Mar 2023 13:20:06 GMT, Johan Sj?len wrote: > Hi, > > This is just a small cleanup where an unnecessary class variable is removed. > > Quoting the issue: > >>class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). > > Please consider, thanks. Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/12828 From jsjolen at openjdk.org Tue Mar 7 07:28:23 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 7 Mar 2023 07:28:23 GMT Subject: Integrated: 8204550: NMT: RegionIterator does not need to keep _current_size In-Reply-To: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> References: <3MJIO6kX0iP9ja-WHUmtZ5QR3n5dbs9QlBeo0WlJKm4=.bae3ca17-24be-42f8-8225-004e7760e7e6@github.com> Message-ID: On Thu, 2 Mar 2023 13:20:06 GMT, Johan Sj?len wrote: > Hi, > > This is just a small cleanup where an unnecessary class variable is removed. > > Quoting the issue: > >>class RegionIteretor does not need to keep _current_size, since that one can be calculated from the three remaining points (start, end of reserved size and current search pointer). > > Please consider, thanks. This pull request has now been integrated. Changeset: 97c25df4 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/97c25df4b8a85c761540f4186b030f81418652eb Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod 8204550: NMT: RegionIterator does not need to keep _current_size Reviewed-by: stuefe, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/12828 From stuefe at openjdk.org Tue Mar 7 10:00:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 7 Mar 2023 10:00:35 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v3] In-Reply-To: <8WXkT33DKx9CjId6BOZ-d_HnbQRB5Slr95U4bWE0qEs=.7d380458-f5fb-4df6-8137-6a69c3e31be0@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> <8WXkT33DKx9CjId6BOZ-d_HnbQRB5Slr95U4bWE0qEs=.7d380458-f5fb-4df6-8137-6a69c3e31be0@github.com> Message-ID: On Mon, 6 Mar 2023 21:01:02 GMT, Justin King wrote: >> Fix memory leaks identified while running Metaspace gtests. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix sign comparision mismatch > > Signed-off-by: Justin King test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 544: > 542: delete node; > 543: ASSERT_EQ(scomm.get(), size_t{0}); > 544: ASSERT_EQ(sres.get(), size_t{0}); While I personally like this, could you please keep cast style as in the rest of the hotspot? C-style or xxx_cast, your call. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From alanb at openjdk.org Tue Mar 7 12:09:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Mar 2023 12:09:42 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: <-rOdC_E6hYCpzF08mXks45wPRTfaKxFNas553VbqlZ4=.5da83163-9d77-486d-bb03-921c246d682b@github.com> On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. If I read this correctly, a JNI attaching thread has its JavaThread on the threads list, the j.l.Thread object is allocated but not yet initialized or the initialization fails (in both cases, holder is null). If a JVMTI agent gets a reference to the thread at this point (GetAllThreads, instrumented the constructor, several other ways) then functions such as GetThreadInfo will attempt to access fields and crash. The changes look okay to me except for SET_FIELDHOLDER_FIELD being a no-op when holder is null. It should be okay for a JVMTI agent to read a default value but if set_priority, set_daemon, or set_thread_status can be being called when the initialization fails then it suggests there the error handling might isn't complete somewhere. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Tue Mar 7 12:32:40 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 12:32:40 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: <-rOdC_E6hYCpzF08mXks45wPRTfaKxFNas553VbqlZ4=.5da83163-9d77-486d-bb03-921c246d682b@github.com> References: <-rOdC_E6hYCpzF08mXks45wPRTfaKxFNas553VbqlZ4=.5da83163-9d77-486d-bb03-921c246d682b@github.com> Message-ID: <7HPdSYJKuGdZiv2RM8IAZS1aiklwUV2QXsHC6g23ow0=.89befe61-4815-4272-a0c9-9ef4e6f40e55@github.com> On Tue, 7 Mar 2023 12:06:27 GMT, Alan Bateman wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > If I read this correctly, a JNI attaching thread has its JavaThread on the threads list, the j.l.Thread object is allocated but not yet initialized or the initialization fails (in both cases, holder is null). If a JVMTI agent gets a reference to the thread at this point (GetAllThreads, instrumented the constructor, several other ways) then functions such as GetThreadInfo will attempt to access fields and crash. > > The changes look okay to me except for SET_FIELDHOLDER_FIELD being a no-op when holder is null. It should be okay for a JVMTI agent to read a default value but if set_priority, set_daemon, or set_thread_status can be being called when the initialization fails then it suggests there the error handling might isn't complete somewhere. @AlanBateman thanks for looking at this. Note that there are no API's for setting the daemon status once the thread is alive (which it is) nor directly changing the thread's status (that can only be done via actions of the thread itself). That only leaves an API call to set the priority as a potential oddity. But I don't see what we can do about it - there is no place to set the priority now it is in the not-yet-existing FieldHolder. Also any such change of priority is either racing with a successful completion of the thread constructor, which will also set priority, or racing with a failed attach in which case the priority value is irrelevant. It is a general flaw that JVMTI allows you to get a hold of a partially initialized thread, and race with the initialization of that thread (the spec says nothing about this possibility - nor should it). So trying to reason what is correct behaviour in such circumstances is very hard. > it suggests there the error handling might isn't complete somewhere I don't understand what you mean by this. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Tue Mar 7 12:35:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 12:35:29 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. Actually if the JVMTI code invokes Thread.setPriority then it will either throw NPE because holder is still null, or else work fine because holder has now been set. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Tue Mar 7 12:45:40 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 12:45:40 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: <6G5cropcaiHWsKOjwjwndR-DfHArs1IUYYXk2tZIfGw=.1b842f46-21c4-4fbf-abb8-2699af0806cb@github.com> On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. I think I have over-thought this. Now that `allocate_threadObj` is fixed I don't think any of the setter functions can ever actually be called on an attaching thread. I'll double-check in the morning, ------------- PR: https://git.openjdk.org/jdk/pull/12892 From jsjolen at openjdk.org Tue Mar 7 13:17:30 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 7 Mar 2023 13:17:30 GMT Subject: RFR: JDK-8301477: Replace NULL with nullptr in os/aix [v2] In-Reply-To: <7tksl5DUVIk0OG0BbLFMxUA6MsYqq7dqMNqt9aAV6UQ=.1c9bcbc1-c1de-49ce-ad1b-cebcef1e3637@github.com> References: <7tksl5DUVIk0OG0BbLFMxUA6MsYqq7dqMNqt9aAV6UQ=.1c9bcbc1-c1de-49ce-ad1b-cebcef1e3637@github.com> Message-ID: On Fri, 17 Feb 2023 09:59:53 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/aix. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Apply Tyler's patch, with some own changes Thanks for the re-approval. ------------- PR: https://git.openjdk.org/jdk/pull/12313 From jsjolen at openjdk.org Tue Mar 7 13:20:30 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 7 Mar 2023 13:20:30 GMT Subject: Integrated: JDK-8301477: Replace NULL with nullptr in os/aix In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 10:15:23 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory os/aix. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! This pull request has now been integrated. Changeset: 43288bbd Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/43288bbd684abfcefdf385ed1e0307070399ccbf Stats: 231 lines in 13 files changed: 0 ins; 3 del; 228 mod 8301477: Replace NULL with nullptr in os/aix Reviewed-by: stuefe, coleenp, tsteele ------------- PR: https://git.openjdk.org/jdk/pull/12313 From jcking at openjdk.org Tue Mar 7 16:41:31 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 7 Mar 2023 16:41:31 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v4] In-Reply-To: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: > Fix memory leaks identified while running Metaspace gtests. Justin King has updated the pull request incrementally with one additional commit since the last revision: Switch to C-style cast Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12865/files - new: https://git.openjdk.org/jdk/pull/12865/files/57df305e..5b368b60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12865&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12865.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12865/head:pull/12865 PR: https://git.openjdk.org/jdk/pull/12865 From jcking at openjdk.org Tue Mar 7 16:41:34 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 7 Mar 2023 16:41:34 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v3] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> <8WXkT33DKx9CjId6BOZ-d_HnbQRB5Slr95U4bWE0qEs=.7d380458-f5fb-4df6-8137-6a69c3e31be0@github.com> Message-ID: <0gKlO22jbzizdayaiKahVGp-gPDbRhIVWzEZLu9WDMU=.d429b963-5592-4bd2-954b-e05c2ef26c88@github.com> On Tue, 7 Mar 2023 09:57:23 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix sign comparision mismatch >> >> Signed-off-by: Justin King > > test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 544: > >> 542: delete node; >> 543: ASSERT_EQ(scomm.get(), size_t{0}); >> 544: ASSERT_EQ(sres.get(), size_t{0}); > > While I personally like this, could you please keep cast style as in the rest of the hotspot? C-style or xxx_cast, your call. Done. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From sviswanathan at openjdk.org Tue Mar 7 17:02:23 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 7 Mar 2023 17:02:23 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The PR looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From stuefe at openjdk.org Tue Mar 7 17:22:48 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 7 Mar 2023 17:22:48 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v4] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: <8KfkFEqJxPa1QKnw_sDsknCiULBpCnAh9YSm7P6t6Nw=.d9dcd272-b1e8-4c98-b34c-5ce4bd1f3f2e@github.com> On Tue, 7 Mar 2023 16:41:31 GMT, Justin King wrote: >> Fix memory leaks identified while running Metaspace gtests. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Switch to C-style cast > > Signed-off-by: Justin King Good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12865 From jbhateja at openjdk.org Tue Mar 7 18:33:11 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 7 Mar 2023 18:33:11 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. public class Foo { public static short bar(float f) {return Float.floatToFloat16(f);} public static void main(String[] args) { System.out.println(Float.floatToRawIntBits(Float.float16ToFloat((short) 31745))); System.out.println(bar(Float.float16ToFloat((short) 31745))); } } CPROMPT>java -Xint -cp . Foo 2143297536 // FP32 QNaN + significand preserved 32257 // FP16 QNaN + significand preserved CPROMPT>java -Xbatch -Xcomp -cp . Foo 2139103232 // FP32 SNaN + significand preserved 31745 // FP16 SNaN + significand preserved CPROMPT>java -XX:-TieredCompilation -Xbatch -Xcomp -cp . Foo 2139103232 // FP32 SNaN + significand preserved 32257 // FP16 QNaN + significand preserved. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 18:41:37 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 18:41:37 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) > Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. And that is fine. Consistency have to be preserved only during one run. Different runs with different flags (with disabled intrinsics, for example) may produce different results. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 18:48:53 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 18:48:53 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments On other hand `-Xint` should not disable intrinsics. I will look. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 19:01:39 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 19:01:39 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: <6vpmSEQIHUeuayoEWhm124zzQY2CgwxG-hydLzjm4Z4=.47ad041b-1c49-4c06-ba9d-66f64f5fb7a1@github.com> On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments It looks like C1 compilation does not invoke intrinsics. Investigating. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 20:28:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 20:28:25 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments We should not allow JIT compilation of `Float.float16ToFloat` and `Float.floatToFloat16` Java methods as we do for other math methods: [abstractInterpreter.hpp#L144](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/abstractInterpreter.hpp#L144) What happens with @jatin-bhateja test is `Float` class is still not loaded when we trigger compilation for `Foo::main` method with `-Xcomp` flag. C2 generates Uncommon trap at the very start of `main()` and code is deoptimized and goes to Interpreter which uses intrinsics. C1 on other hand generates calls to `Float.float16ToFloat` and `Float.floatToFloat16` in compiled `Foo::main` method and then compiles `Float.float16ToFloat` and `Float.floatToFloat16` which are called. The fix ix simple: +++ b/src/hotspot/share/interpreter/abstractInterpreter.hpp @@ -159,6 +159,8 @@ class AbstractInterpreter: AllStatic { case vmIntrinsics::_dexp : // fall thru case vmIntrinsics::_fmaD : // fall thru case vmIntrinsics::_fmaF : // fall thru + case vmIntrinsics::_floatToFloat16 : // fall thru + case vmIntrinsics::_float16ToFloat : // fall thru case vmIntrinsics::_Continuation_doYield : // fall thru return false; test now produce the same result: $ java -Xint Foo 2143297536 32257 $ java -Xcomp -XX:-TieredCompilation Foo 2143297536 32257 $ java -Xcomp -XX:TieredStopAtLevel=1 Foo 2143297536 32257 ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 20:35:04 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 20:35:04 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2] In-Reply-To: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> References: <9xh4y5OLD7_ZgSgnRtBk8dUWEODYa9ut3H19y3XNGxw=.d21814f5-ac8f-4786-98ff-53b926f0ad8e@github.com> Message-ID: <_z_y5VwjSFljVZjnn-lM7X6ecLtPpkSSSfKEiFjDCA4=.2d84e402-c22c-40e3-9a05-40977fd2ed63@github.com> On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments C2 also compiled `float16ToFloat`. That is why we got `FP32 SNaN` result with `-XX:-TieredCompilation` in Jatin's example. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From matsaave at openjdk.org Tue Mar 7 21:27:54 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 7 Mar 2023 21:27:54 GMT Subject: RFR: 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) Message-ID: The path parameter is no longer used in the method `ClassLoader::add_to_app_classpath_entries` so it can be safely removed. Verified with tier 1-4 tests. ------------- Commit messages: - 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) Changes: https://git.openjdk.org/jdk/pull/12889/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12889&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303495 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12889/head:pull/12889 PR: https://git.openjdk.org/jdk/pull/12889 From kvn at openjdk.org Tue Mar 7 21:38:38 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 21:38:38 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/9302d4bc..ed01863d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Tue Mar 7 21:38:40 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 7 Mar 2023 21:38:40 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 18:28:46 GMT, Jatin Bhateja wrote: >> @sviswa7 I update changes based on your comments. Please, look: [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) > > Hi @vnkozlov , There is some discrepancy in results b/w interpreter, C1 and C2 for following case. > > public class Foo { > public static short bar(float f) {return Float.floatToFloat16(f);} > public static void main(String[] args) { > System.out.println(Float.floatToRawIntBits(Float.float16ToFloat((short) 31745))); > System.out.println(bar(Float.float16ToFloat((short) 31745))); > } > } > > CPROMPT>java -Xint -cp . Foo > 2143297536 // FP32 QNaN + significand preserved > 32257 // FP16 QNaN + significand preserved > CPROMPT>java -Xbatch -Xcomp -cp . Foo > 2139103232 // FP32 SNaN + significand preserved > 31745 // FP16 SNaN + significand preserved > CPROMPT>java -XX:-TieredCompilation -Xbatch -Xcomp -cp . Foo > 2139103232 // FP32 SNaN + significand preserved > 32257 // FP16 QNaN + significand preserved. @jatin-bhateja I applied the fix. Please, verify. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From ccheung at openjdk.org Tue Mar 7 22:50:06 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 7 Mar 2023 22:50:06 GMT Subject: RFR: 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:15:56 GMT, Matias Saavedra Silva wrote: > The path parameter is no longer used in the method `ClassLoader::add_to_app_classpath_entries` so it can be safely removed. Verified with tier 1-4 tests. Looks good and trivial. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12889 From dholmes at openjdk.org Tue Mar 7 22:58:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 22:58:19 GMT Subject: Integrated: 8303151: DCmd framework cleanups In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 04:59:44 GMT, David Holmes wrote: > Whilst working on the DCmd code I noticed two items that could be cleaned up: > > 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead of inside it. > > 2. The "extension" mechanism to define external DCmds (as added by [JDK-7132515](https://bugs.openjdk.org/browse/JDK-7132515) for `UnlockCommercialFeatures`) is no longer needed. > > Testing: tiers 1-3 > > Thanks This pull request has now been integrated. Changeset: 5f1108f8 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/5f1108f8f0768837591b06d47dec857963ed1fcb Stats: 32 lines in 3 files changed: 6 ins; 23 del; 3 mod 8303151: DCmd framework cleanups Reviewed-by: jsjolen, stuefe, yyang ------------- PR: https://git.openjdk.org/jdk/pull/12847 From dholmes at openjdk.org Tue Mar 7 22:58:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 22:58:47 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v2] In-Reply-To: References: Message-ID: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restore setter methods to assert holder!=nullptr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12892/files - new: https://git.openjdk.org/jdk/pull/12892/files/40382015..6a145ee0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12892.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12892/head:pull/12892 PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Tue Mar 7 22:58:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Mar 2023 22:58:49 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. I re-examined the setter methods and none of them can be called on a JNI attaching thread whilst it is partially constructed. Such a thread could have regular Java methods called on it, but they would throw NPE when trying to access the FieldHolder. So it suffices to keep the assertion that holder!=nullptr in the setter methods. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From jcking at openjdk.org Wed Mar 8 01:05:14 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Mar 2023 01:05:14 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v4] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Sat, 4 Mar 2023 09:29:44 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to C-style cast >> >> Signed-off-by: Justin King > > test/hotspot/gtest/metaspace/test_virtualspacenode.cpp line 506: > >> 504: >> 505: VirtualSpaceNode* node = VirtualSpaceNode::create_node(word_size, &cl, &sres, &scomm); >> 506: > > please remove whitespace change Believe I have. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From fyang at openjdk.org Wed Mar 8 01:57:31 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 8 Mar 2023 01:57:31 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 21:38:38 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 Hi, Thanks for handling linux-riscv64 at the same time. Bad news is that we witnessed test failures when running following test with QEMU (no riscv hardware available with Zfhmin extension for now): test/hotspot/jtreg/compiler/intrinsics/float16/TestAllFloat16ToFloat.java Exception in thread "main" java.lang.RuntimeException: Inconsistent result for Float.floatToFloat16(NaN/7fc00000): 7e00 != fc01 at TestAllFloat16ToFloat.verify(TestAllFloat16ToFloat.java:62) at TestAllFloat16ToFloat.run(TestAllFloat16ToFloat.java:72) at TestAllFloat16ToFloat.main(TestAllFloat16ToFloat.java:94) It looks like there is a problem when handling NaNs with fcvt.h.s/fmv.x.h and fmv.h.x/fcvt.s.h instructions at the bottom. It's also possible to be an issue of QEMU as well. It would take quite a while to diagnose. But I don't want this to block this PR. So I would prefer removing support of this feature for this port and adding back once this is resolved. And I have prepared a patch for that purpose. See attachement. [12869-revert-riscv.txt](https://github.com/openjdk/jdk/files/10915606/12869-revert-riscv.txt) ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 05:17:53 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 05:17:53 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove RISC-V port code for float16 intrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/ed01863d..9f4b2474 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=02-03 Stats: 130 lines in 13 files changed: 0 ins; 116 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 05:17:56 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 05:17:56 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 01:53:14 GMT, Fei Yang wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Do not allow JIT compilation of Float.float16ToFloat and Float.floatToFloat16 > > Hi, Thanks for handling linux-riscv64 at the same time. > Bad news is that we witnessed test failures when running following test with QEMU (no riscv hardware available with Zfhmin extension for now): test/hotspot/jtreg/compiler/intrinsics/float16/TestAllFloat16ToFloat.java > > > Exception in thread "main" java.lang.RuntimeException: Inconsistent result for Float.floatToFloat16(NaN/7fc00000): 7e00 != fc01 > at TestAllFloat16ToFloat.verify(TestAllFloat16ToFloat.java:62) > at TestAllFloat16ToFloat.run(TestAllFloat16ToFloat.java:72) > at TestAllFloat16ToFloat.main(TestAllFloat16ToFloat.java:94) > > > It looks like there is a problem when handling NaNs with fcvt.h.s/fmv.x.h and fmv.h.x/fcvt.s.h instructions at the bottom. > It's also possible to be an issue of QEMU as well. It would take quite a while to diagnose. But I don't want this to block this PR. > So I would prefer removing support of this feature for this port and adding back once this is resolved. And I have prepared a patch for that purpose. See attachement. > [12869-revert-riscv.txt](https://github.com/openjdk/jdk/files/10915606/12869-revert-riscv.txt) Thank you very much @RealFYang for testing changes and preparing patch. I applied your patch. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Wed Mar 8 08:00:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 08:00:14 GMT Subject: RFR: 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Mon, 6 Mar 2023 21:15:56 GMT, Matias Saavedra Silva wrote: > The path parameter is no longer used in the method `ClassLoader::add_to_app_classpath_entries` so it can be safely removed. Verified with tier 1-4 tests. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12889 From alanb at openjdk.org Wed Mar 8 08:20:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Mar 2023 08:20:16 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v2] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 22:58:47 GMT, David Holmes wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore setter methods to assert holder!=nullptr Marked as reviewed by alanb (Reviewer). src/hotspot/share/classfile/javaClasses.cpp line 1637: > 1635: // Convenience macros for setting and getting Thread fields that > 1636: // are actually stored in the FieldHolder object of the thread. > 1637: // The FieldHolder can be null whilst a thread is attaching via JNI. Also the primordial thread. A JVMTI agent with the can_generate_early_vmstart capability sees the start phase before create_initial_thread and so many instrument some classes that are loaded early in the startup. Agents playing in this phase of startup are playing with fire of course. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From jbhateja at openjdk.org Wed Mar 8 08:39:27 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 8 Mar 2023 08:39:27 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <7DG9mLetq1UlaCe0EbNx-Lvk6roh05PalMDwmGsPQwU=.a6a01b6a-8575-49d5-a8d9-d31eee93ad25@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Hi @vnkozlov , Thanks for explanations, looks good to me now. ------------- Marked as reviewed by jbhateja (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From jwaters at openjdk.org Wed Mar 8 08:47:37 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 8 Mar 2023 08:47:37 GMT Subject: RFR: 8303810: Move attribute of FileMapInfo::fail_stop to match JDK-8302124 Message-ID: Cleanup of [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) to move an attribute missed in it to match the HotSpot Style Guide's required attribute position ------------- Commit messages: - 8303810: Move attribute of FileMapInfo::fail_stop to match JDK-8302124 Changes: https://git.openjdk.org/jdk/pull/12918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303810 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12918.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12918/head:pull/12918 PR: https://git.openjdk.org/jdk/pull/12918 From dholmes at openjdk.org Wed Mar 8 09:34:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 09:34:06 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v4] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Tue, 7 Mar 2023 16:41:31 GMT, Justin King wrote: >> Fix memory leaks identified while running Metaspace gtests. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Switch to C-style cast > > Signed-off-by: Justin King Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12865 From thartmann at openjdk.org Wed Mar 8 10:00:07 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 8 Mar 2023 10:00:07 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:16:08 GMT, Vladimir Kozlov wrote: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. Looks good to me. src/hotspot/share/opto/c2compiler.hpp line 68: > 66: // Check if the compiler supports an intrinsic for 'method' given the > 67: // the dispatch mode specified by the 'is_virtual' parameter. > 68: bool is_virtual_intrinsic_supported(vmIntrinsics::ID id, bool is_virtual); I find the new name of the method confusing because it suggests that the intrinsic is always virtual. Can we keep the old name? ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/12858 From jcking at openjdk.org Wed Mar 8 15:41:58 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Mar 2023 15:41:58 GMT Subject: RFR: JDK-8303605: Memory leaks in Metaspace gtests [v4] In-Reply-To: References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Tue, 7 Mar 2023 16:41:31 GMT, Justin King wrote: >> Fix memory leaks identified while running Metaspace gtests. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Switch to C-style cast > > Signed-off-by: Justin King Failed GHA is unrelated. ------------- PR: https://git.openjdk.org/jdk/pull/12865 From jcking at openjdk.org Wed Mar 8 15:42:00 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Mar 2023 15:42:00 GMT Subject: Integrated: JDK-8303605: Memory leaks in Metaspace gtests In-Reply-To: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> References: <_5-mmkaYx8JiXOFYMDV2AoilnC5euutU2hkltFYuhaE=.43e6bf2b-f6b6-4aff-8f0a-b2fbf08fe117@github.com> Message-ID: On Fri, 3 Mar 2023 19:40:40 GMT, Justin King wrote: > Fix memory leaks identified while running Metaspace gtests. This pull request has now been integrated. Changeset: ddcb369c Author: Justin King URL: https://git.openjdk.org/jdk/commit/ddcb369ceabd2207699632e90a358baf251c6f36 Stats: 20 lines in 4 files changed: 19 ins; 0 del; 1 mod 8303605: Memory leaks in Metaspace gtests Reviewed-by: stuefe, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12865 From matsaave at openjdk.org Wed Mar 8 15:45:53 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 8 Mar 2023 15:45:53 GMT Subject: RFR: 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 22:47:13 GMT, Calvin Cheung wrote: >> The path parameter is no longer used in the method `ClassLoader::add_to_app_classpath_entries` so it can be safely removed. Verified with tier 1-4 tests. > > Looks good and trivial. Thanks for the reviews @calvinccheung and @dholmes-ora. ------------- PR: https://git.openjdk.org/jdk/pull/12889 From jcking at openjdk.org Wed Mar 8 15:46:25 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Mar 2023 15:46:25 GMT Subject: RFR: JDK-8301990: Separate Arguments::parse into two phases [v3] In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 10:56:01 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename PreprocessedImpl to PreprocessedArguments >> >> Signed-off-by: Justin King > > I am not convinced that the reason behind this change - getting rid of NMTPreInit - is something we should do. See my comments under https://bugs.openjdk.org/browse/JDK-8299196. I think we should discuss that first. > > I did not look at this patch to see if it has merits beyond that. This is not necessary anymore due to recent changes by @tstuefe. Closing. ------------- PR: https://git.openjdk.org/jdk/pull/12458 From jcking at openjdk.org Wed Mar 8 15:46:26 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 8 Mar 2023 15:46:26 GMT Subject: Withdrawn: JDK-8301990: Separate Arguments::parse into two phases In-Reply-To: References: Message-ID: <2ofEiCv6s7cOnVbFbnpG0x-H3rNZKSskb7gWGaG4nBc=.1a68d8b9-7475-4486-b526-ce35465c7667@github.com> On Tue, 7 Feb 2023 16:21:07 GMT, Justin King wrote: > Separate out some logic from `Arguments::parse` into a separate preceding phase, preprocessing. See JDK-8301990 and JDK-8299196 for more details. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12458 From matsaave at openjdk.org Wed Mar 8 15:54:58 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 8 Mar 2023 15:54:58 GMT Subject: RFR: 8281941: Change CDS warning messages to use Unified Logging Message-ID: As an addendum to previous commits that changed CDS logging, this replaces the remaining log messages with Unified logging. There are also old warning messages that used to be prefixed with UseSharedSpaces which have been updated along with their tests. ------------- Commit messages: - Fixed compilation error and tests - 8281941: Change CDS warning messages to use Unified Logging Changes: https://git.openjdk.org/jdk/pull/12890/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12890&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8281941 Stats: 17 lines in 7 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/12890.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12890/head:pull/12890 PR: https://git.openjdk.org/jdk/pull/12890 From coleenp at openjdk.org Wed Mar 8 16:37:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 8 Mar 2023 16:37:23 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 14:50:34 GMT, Frederic Parain wrote: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. I was able to do a first pass through the vm code except for jvmci. I didn't look at tests or SA in this pass. src/hotspot/share/ci/ciFlags.hpp line 47: > 45: > 46: ciFlags() { _flags = 0; _stable = false; _intialized_final_update = false; } > 47: ciFlags(AccessFlags flags, bool is_stable= false, bool is_initialized_final_update = false) { This should use constructor initializer syntax. src/hotspot/share/classfile/classFileParser.cpp line 1491: > 1489: _temp_field_info = new GrowableArray(total_fields); > 1490: > 1491: ResourceMark rm(THREAD); Is the ResourceMark ok here or should it go before allocating _temp_field_info ? src/hotspot/share/classfile/classFileParser.cpp line 1608: > 1606: fflags.update_injected(true); > 1607: AccessFlags aflags; > 1608: FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags); I don't know why there's a cast here until I read more. If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead? src/hotspot/share/classfile/classFileParser.cpp line 1634: > 1632: for(int i = 0; i < _temp_field_info->length(); i++) { > 1633: name = _temp_field_info->adr_at(i)->name(_cp); > 1634: sig = _temp_field_info->adr_at(i)->signature(_cp); This checking for duplicates looks like a good candidate for a separate function because parse_fields is so long. I'm adding this comment to remember to file an RFE to look into making this function shorter and factor out this code. src/hotspot/share/classfile/classFileParser.cpp line 6024: > 6022: int injected_fields_count = _temp_field_info->length() - _java_fields_count; > 6023: _fieldinfo_stream = FieldInfoStream::create_FieldInfoStream(_temp_field_info, _java_fields_count, injected_fields_count, loader_data(), CHECK); > 6024: _fields_status = MetadataFactory::new_array(_loader_data, _temp_field_info->length(), FieldStatus(0), CHECK); These lines seem long, could you reformat? src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 554: > 552: FieldInfo ctrl = _field_info->at(0); > 553: FieldGroup* group = nullptr; > 554: FieldInfo tfi = *it; What's the 't' in tfi? Maybe a longer variable name would be helpful here. src/hotspot/share/classfile/javaClasses.cpp line 871: > 869: // a new UNSIGNED5 stream, and substitute it to the old FieldInfo stream. > 870: > 871: int java_fields; Can you put InstanceKlass* ik = InstanceKlass::cast(k); here and use that so there's only one cast? src/hotspot/share/classfile/javaClasses.cpp line 873: > 871: int java_fields; > 872: int injected_fields; > 873: GrowableArray* fields = FieldInfoStream::create_FieldInfoArray(InstanceKlass::cast(k)->fieldinfo_stream(), &java_fields, &injected_fields); This line looks too long too. src/hotspot/share/oops/fieldInfo.hpp line 31: > 29: #include "memory/metadataFactory.hpp" > 30: #include "oops/constantPool.hpp" > 31: #include "oops/symbol.hpp" Since you added an inline.hpp function can you move the functions that rely on including constantPool.hpp, symbol.hpp and metadataFactory.hpp into the inline.hpp file? src/hotspot/share/oops/fieldInfo.hpp line 180: > 178: u2 generic_signature_index() const { return _generic_signature_index; } > 179: void set_generic_signature_index(u2 index) { _generic_signature_index = index; } > 180: u2 contention_group() const { return _contention_group; } Can you align the { in these one line functions? src/hotspot/share/oops/fieldStreams.hpp line 28: > 26: #define SHARE_OOPS_FIELDSTREAMS_HPP > 27: > 28: #include "oops/instanceKlass.inline.hpp" including .inline.hpp from .hpp is against the guidelines. You should move things and include instanceKlass.inline.hpp in fieldStreams.inline.hpp instead. src/hotspot/share/oops/fieldStreams.hpp line 104: > 102: AccessFlags flags; > 103: flags.set_flags(field()->access_flags()); > 104: return flags; Did this used to do this for a reason? src/hotspot/share/oops/fieldStreams.inline.hpp line 28: > 26: #define SHARE_OOPS_FIELDSTREAMS_INLINE_HPP > 27: > 28: #include "oops/fieldInfo.inline.hpp" I don't know if you have to include oops/fieldInfo.inline.hpp but the include line for fieldStreams.hpp should be by itself and then this new include should be below with runtime/javaThread.hpp src/hotspot/share/oops/instanceKlass.hpp line 275: > 273: // Fields information is stored in an UNSIGNED5 encoded stream (see fieldInfo.hpp) > 274: Array* _fieldinfo_stream; > 275: Array* _fields_status; Can you align these two field identifiers? src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 3582: > 3580: } > 3581: if (update_required) { > 3582: Array* old_stream = InstanceKlass::cast(scratch_class)->fieldinfo_stream(); scratch_class should already be an InstanceKlass, ie cast not required here or below. src/hotspot/share/runtime/reflectionUtils.hpp line 29: > 27: > 28: #include "memory/allStatic.hpp" > 29: #include "oops/instanceKlass.inline.hpp" Also here cannot include .inline.hpp in .hpp file. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12855 From kvn at openjdk.org Wed Mar 8 18:20:27 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 18:20:27 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 09:55:47 GMT, Tobias Hartmann wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > src/hotspot/share/opto/c2compiler.hpp line 68: > >> 66: // Check if the compiler supports an intrinsic for 'method' given the >> 67: // the dispatch mode specified by the 'is_virtual' parameter. >> 68: bool is_virtual_intrinsic_supported(vmIntrinsics::ID id, bool is_virtual); > > I find the new name of the method confusing because it suggests that the intrinsic is always virtual. Can we keep the old name? We still have `is_intrinsic_supported()` declared at line 64. New `is_virtual_intrinsic_supported()` is added to handle only virtual intrinsics`_hashCode` and `_clone`. I simply moved these intrinsics handling into separate method because it is used only by C2 in `library_call.cpp`. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From thartmann at openjdk.org Wed Mar 8 18:59:39 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 8 Mar 2023 18:59:39 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> On Wed, 8 Mar 2023 18:17:50 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/opto/c2compiler.hpp line 68: >> >>> 66: // Check if the compiler supports an intrinsic for 'method' given the >>> 67: // the dispatch mode specified by the 'is_virtual' parameter. >>> 68: bool is_virtual_intrinsic_supported(vmIntrinsics::ID id, bool is_virtual); >> >> I find the new name of the method confusing because it suggests that the intrinsic is always virtual. Can we keep the old name? > > We still have `is_intrinsic_supported()` declared at line 64. New `is_virtual_intrinsic_supported()` is added to handle only virtual intrinsics`_hashCode` and `_clone`. I simply moved these intrinsics handling into separate method because it is used only by C2 in `library_call.cpp`. Okay, got it. Thanks for the explanation. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From vlivanov at openjdk.org Wed Mar 8 19:46:14 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 19:46:14 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Overall, looks good. Minor comments/suggestions follow. src/hotspot/share/opto/convertnode.cpp line 171: > 169: if (t == Type::TOP) return Type::TOP; > 170: if (t == Type::FLOAT) return TypeInt::SHORT; > 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. src/hotspot/share/opto/convertnode.cpp line 244: > 242: > 243: const TypeInt *ti = t->is_int(); > 244: if (ti->is_con()) { I find it confusing that `ConvHF2FNode::Value()` has `is_con()` check, but `ConvF2HFNode::Value()`doesn't. I'd prefer to see both implementations unified. src/hotspot/share/runtime/sharedRuntime.cpp line 451: > 449: assert(StubRoutines::f2hf() != nullptr, "floatToFloat16 intrinsic is not supported on this platform"); > 450: typedef jshort (*f2hf_stub_t)(jfloat x); > 451: return ((f2hf_stub_t)StubRoutines::f2hf())(x); What's the point of keeping the wrappers around? The stubs can be called directly, can't they? ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 21:14:19 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:14:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <5OfHFOlt05wJhzyU1Rpce3xx3B4BnO-dEF6X0I1JgD8=.1135fdd9-ae96-45d9-a26c-ad22f721bad7@github.com> On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics Thank you for review @iwanowww ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 21:14:23 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:14:23 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: On Wed, 8 Mar 2023 19:38:56 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/share/opto/convertnode.cpp line 171: > >> 169: if (t == Type::TOP) return Type::TOP; >> 170: if (t == Type::FLOAT) return TypeInt::SHORT; >> 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); > > What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. This code is optimization: use stub to calculate constant value during compilation instead of generating HW instruction in compiled code. It is not required to have this stub for intensification to work - `ConvF2HFNode` will be processed normally and will use intrinsics code (HW instruction) defined in .ad file. These stubs are used only here, not in C1 and not in Interpreter. As consequence these stubs implementation is optional and I implemented them only on x64. That is why I have this check. I debated to not have them at all to not confuse people but they did improve performance a little. > src/hotspot/share/opto/convertnode.cpp line 244: > >> 242: >> 243: const TypeInt *ti = t->is_int(); >> 244: if (ti->is_con()) { > > I find it confusing that `ConvHF2FNode::Value()` has `is_con()` check, but `ConvF2HFNode::Value()`doesn't. I'd prefer to see both implementations unified. It follows the same pattern as other nodes here: `ConvF2INode::Value()` vs `ConvI2FNode::Value()`. If you want to change it we need to do that in separate RFE for all methods here. But I don't think we need to do that because Float/Double does not have range values as Integer types. Float have only 3 types of value: FloatTop, FloatBot, FloatCon. So we don't need to check for constant if checked for TOP and BOT. For Integer we need to check `bool is_con() const { return _lo==_hi; }`. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 21:22:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 21:22:25 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: <53sy823UIcXi4OTG8SgGnjrUmkOymF2L62BHoFkTgPk=.5de6fcd3-ea94-4f6a-8c1b-2ccf243374fd@github.com> On Wed, 8 Mar 2023 19:04:01 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/share/runtime/sharedRuntime.cpp line 451: > >> 449: assert(StubRoutines::f2hf() != nullptr, "floatToFloat16 intrinsic is not supported on this platform"); >> 450: typedef jshort (*f2hf_stub_t)(jfloat x); >> 451: return ((f2hf_stub_t)StubRoutines::f2hf())(x); > > What's the point of keeping the wrappers around? The stubs can be called directly, can't they? I wanted isolate function type cast and assert in one place. BTW the comment in assert should be "the stub is not implemented on this platform". ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dcubed at openjdk.org Wed Mar 8 21:27:15 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 8 Mar 2023 21:27:15 GMT Subject: Integrated: 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 Message-ID: This reverts commit 5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35. ------------- Commit messages: - Revert "8302189: Mark assertion failures noreturn" Changes: https://git.openjdk.org/jdk/pull/12933/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303839 Stats: 165 lines in 8 files changed: 19 ins; 125 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/12933.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12933/head:pull/12933 PR: https://git.openjdk.org/jdk/pull/12933 From dholmes at openjdk.org Wed Mar 8 21:27:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Mar 2023 21:27:16 GMT Subject: Integrated: 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 20:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35. Looks like an accurate backout. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12933 From dcubed at openjdk.org Wed Mar 8 21:27:17 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 8 Mar 2023 21:27:17 GMT Subject: Integrated: 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 20:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35. I have an urgent Mach5 Tier1 job that has passed 8 of 32 build tasks so far... All build tasks have passed as have 86 of the test tasks; 9 test tasks are still running, but... ------------- PR: https://git.openjdk.org/jdk/pull/12933 From dcubed at openjdk.org Wed Mar 8 21:27:18 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 8 Mar 2023 21:27:18 GMT Subject: Integrated: 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 21:03:35 GMT, David Holmes wrote: >> This reverts commit 5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35. > > Looks like an accurate backout. Thanks @dholmes-ora - Thanks for the fast review! The Mach5 Tier1 is doing well... but is not yet done... ------------- PR: https://git.openjdk.org/jdk/pull/12933 From dcubed at openjdk.org Wed Mar 8 21:27:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 8 Mar 2023 21:27:19 GMT Subject: Integrated: 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 In-Reply-To: References: Message-ID: <_5u7oxRI3KpEJDvp24KUo4B7BjIrR0xp24c-P_NisaM=.df3980de-22be-4daf-9f22-7178240c26a8@github.com> On Wed, 8 Mar 2023 20:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 5fa9bd458232a0b5f31b1e7e5a4a2b1f4047da35. This pull request has now been integrated. Changeset: 25de2228 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/25de2228ac3295ea7d0574ce386d5c84d8ed68b1 Stats: 165 lines in 8 files changed: 19 ins; 125 del; 21 mod 8303839: [BACKOUT] JDK-8302799 and JDK-8302189 Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12933 From vlivanov at openjdk.org Wed Mar 8 21:44:18 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 21:44:18 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: On Wed, 8 Mar 2023 20:55:29 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/opto/convertnode.cpp line 171: >> >>> 169: if (t == Type::TOP) return Type::TOP; >>> 170: if (t == Type::FLOAT) return TypeInt::SHORT; >>> 171: if (StubRoutines::f2hf() == nullptr) return bottom_type(); >> >> What's the purpose of this check? My understanding is ConvF2HF/ConvHF2F require intrinsification and on platforms where stubs are absent, intrinsification is disabled. > > This code is optimization: use stub to calculate constant value during compilation instead of generating HW instruction in compiled code. It is not required to have this stub for intensification to work - `ConvF2HFNode` will be processed normally and will use intrinsics code (HW instruction) defined in .ad file. > These stubs are used only here, not in C1 and not in Interpreter. As consequence these stubs implementation is optional and I implemented them only on x64. That is why I have this check. > I debated to not have them at all to not confuse people but they did improve performance a little. Thanks for the clarifications. Now it makes much more sense. Still, the mix of `StubRoutines::f2hf()` and `SharedRuntime::f2hf()` looks a bit confusing. What if you move the wrapper to `StubRoutines` class instead? (`JRT_LEAF` et al stuff looks redundant here. Also, even though there are other arithmetic operations declared on `StubRoutines`, they provide default implementations universally available across all platforms. `f2hf` case is different since it exposes a platform-specific stub and its availability is limited.) Or encapsulate the constant folding logic (along with the guard) into `SharedRuntime` and return `Type*` (instead of int/float scalar). ------------- PR: https://git.openjdk.org/jdk/pull/12869 From vlivanov at openjdk.org Wed Mar 8 21:50:17 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 21:50:17 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: <1WK1RTMCYwOXw7LvaJr04fL68nN64TpB05fcPC2a3uo=.d71b77a8-c814-4166-8f56-af97ac70dc55@github.com> Message-ID: <-P79Z2uDRHMZk2XTPNY9MidCv-H4t9Cj2Rot1aEj0Cg=.cc46bdde-0e11-4252-b2d7-96ee906c7f04@github.com> On Wed, 8 Mar 2023 21:41:31 GMT, Vladimir Ivanov wrote: > Or encapsulate the constant folding logic (along with the guard) into SharedRuntime and return Type* (instead of int/float scalar). I take this particular suggestion back. `SharedRuntime` is compiler-agnostic while `Type` is C2-specific. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dlong at openjdk.org Wed Mar 8 22:30:19 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 8 Mar 2023 22:30:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: > 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame > 3533: __ ret(0); > 3534: Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 22:54:17 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 22:54:17 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove RISC-V port code for float16 intrinsics > What if you move the wrapper to StubRoutines class instead? Okay, I will try it. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 22:54:19 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 22:54:19 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: References: Message-ID: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> On Wed, 8 Mar 2023 22:27:31 GMT, Dean Long wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove RISC-V port code for float16 intrinsics > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: > >> 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame >> 3533: __ ret(0); >> 3534: > > Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. I think you are right. These stubs are not called from compiled code, only from C++ (C2) code during compilation. Let me test it. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Wed Mar 8 23:14:05 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 8 Mar 2023 23:14:05 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove SharedRuntime::f2hf and hf2f wrapper functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12869/files - new: https://git.openjdk.org/jdk/pull/12869/files/9f4b2474..fa799942 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12869&range=03-04 Stats: 43 lines in 5 files changed: 15 ins; 20 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12869.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12869/head:pull/12869 PR: https://git.openjdk.org/jdk/pull/12869 From vlivanov at openjdk.org Wed Mar 8 23:40:09 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 8 Mar 2023 23:40:09 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove SharedRuntime::f2hf and hf2f wrapper functions Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Thu Mar 9 00:04:09 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 00:04:09 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4] In-Reply-To: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> References: <-bRTiJ15e_f536NOqVIIge5Q_Ij1YwZVtS1Ciew-XDY=.9cbea18b-3202-4b76-a4aa-618005d4677b@github.com> Message-ID: <3vTFng8nGQ-gFMkTzyexYknU4McM_8mzY5b6699QFaE=.ccd9b65f-fb69-49a4-b174-1847cdee3ebb@github.com> On Wed, 8 Mar 2023 22:49:42 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3534: >> >>> 3532: __ leave(); // required for proper stackwalking of RuntimeStub frame >>> 3533: __ ret(0); >>> 3534: >> >> Do we really need to set up a stack frame for these two? This should be a leaf, and we have other leaf stubs that don't set up a frame. > > I think you are right. These stubs are not called from compiled code, only from C++ (C2) code during compilation. > Let me test it. Testing passed with `enter()` and `leave()` removed ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Thu Mar 9 00:09:10 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 00:09:10 GMT Subject: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v5] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 23:14:05 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. >> >> Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. >> >> I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. >> >> Tested tier1-5, Xcomp, stress > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove SharedRuntime::f2hf and hf2f wrapper functions Thank you, Vladimir and Dean for review. ------------- PR: https://git.openjdk.org/jdk/pull/12869 From dholmes at openjdk.org Thu Mar 9 02:37:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 02:37:07 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: <14u458Y0fDM8iouM3LGbvnQZKw5FzRoVmgKchzOUpsk=.1abcb17b-53dd-4524-9942-be9e3ec6a358@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Fri, 3 Mar 2023 16:16:08 GMT, Vladimir Kozlov wrote: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. Just a couple of drive-by comments. I'm a bit confused about the core issue of " Add VM_Version::is_intrinsic_supported(id)" because AFAICS this was only added for x86 ?? src/hotspot/cpu/x86/vm_version_x86.cpp line 3230: > 3228: case vmIntrinsics::_floatToFloat16: > 3229: case vmIntrinsics::_float16ToFloat: > 3230: if (!supports_f16c() && !supports_avx512vl()) return false; Please put the return on a new line - it is too easy to just see the break. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Thu Mar 9 02:37:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 02:37:08 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> References: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> Message-ID: On Wed, 8 Mar 2023 18:56:55 GMT, Tobias Hartmann wrote: >> We still have `is_intrinsic_supported()` declared at line 64. New `is_virtual_intrinsic_supported()` is added to handle only virtual intrinsics`_hashCode` and `_clone`. I simply moved these intrinsics handling into separate method because it is used only by C2 in `library_call.cpp`. > > Okay, got it. Thanks for the explanation. Okay but then why do we still need the parameter `is_virtual`? ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 03:30:30 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 03:30:30 GMT Subject: Integrated: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 21:41:35 GMT, Vladimir Kozlov wrote: > Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in Interpreter and C1 compiler to produce the same results as C2 intrinsics on x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java methods were implemented originally. > > Replaced `SharedRuntime::f2hf()` and `hf2f()` C runtime functions with calls to runtime stubs which use the same HW instructions as C2 intrinsics. Only for 64-bit x64 because 32-bit x86 stub does not work: result is passed through FPU register and NaN values become different from C2 intrinsic. This runtime stub is only used to calculate constant values during C2 compilation and can be skipped. > > I added new tests based on Tobias's `TestAll.java` And copied `jdk/lang/Float/Binary16Conversion*.java` tests to run them with `-Xcomp` to make sure code is compiled by C1 or C2. I modified `Binary16ConversionNaN.java` to compare results from Interpreter, C1 and C2. > > Tested tier1-5, Xcomp, stress This pull request has now been integrated. Changeset: 8cfd74f7 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/8cfd74f76afc9e5d50c52104fef9974784718dd4 Stats: 1408 lines in 47 files changed: 1213 ins; 154 del; 41 mod 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter Reviewed-by: sviswanathan, jbhateja, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/12869 From kvn at openjdk.org Thu Mar 9 03:32:15 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 03:32:15 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: <14u458Y0fDM8iouM3LGbvnQZKw5FzRoVmgKchzOUpsk=.1abcb17b-53dd-4524-9942-be9e3ec6a358@github.com> References: <14u458Y0fDM8iouM3LGbvnQZKw5FzRoVmgKchzOUpsk=.1abcb17b-53dd-4524-9942-be9e3ec6a358@github.com> Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 9 Mar 2023 02:19:44 GMT, David Holmes wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > src/hotspot/cpu/x86/vm_version_x86.cpp line 3230: > >> 3228: case vmIntrinsics::_floatToFloat16: >> 3229: case vmIntrinsics::_float16ToFloat: >> 3230: if (!supports_f16c() && !supports_avx512vl()) return false; > > Please put the return on a new line - it is too easy to just see the break. Okay. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 04:02:12 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 04:02:12 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> Message-ID: On Thu, 9 Mar 2023 02:28:44 GMT, David Holmes wrote: >> Okay, got it. Thanks for the explanation. > > Okay but then why do we still need the parameter `is_virtual`? @dholmes-ora I can remove parameter if I modify caller code like next: - is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()) && - compiler->is_virtual_intrinsic_supported(id, is_virtual); + is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()); + if (is_available && is_virtual) { + is_available = compiler->is_virtual_intrinsic_supported(id); + } Will it satisfy you? ------------- PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Thu Mar 9 04:35:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 04:35:07 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> Message-ID: On Thu, 9 Mar 2023 03:59:35 GMT, Vladimir Kozlov wrote: >> Okay but then why do we still need the parameter `is_virtual`? > > @dholmes-ora I can remove parameter if I modify caller code like next: > > - is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()) && > - compiler->is_virtual_intrinsic_supported(id, is_virtual); > + is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()); > + if (is_available && is_virtual) { > + is_available = compiler->is_virtual_intrinsic_supported(id); > + } > > Will it satisfy you? How many callers are there? From an API design perspective this method is either only for virtual intrinsics, so no parameter needed, or it is for general intrinsics and the parameter indicates what type. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 05:06:15 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 05:06:15 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> Message-ID: On Thu, 9 Mar 2023 04:32:06 GMT, David Holmes wrote: >> @dholmes-ora I can remove parameter if I modify caller code like next: >> >> - is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()) && >> - compiler->is_virtual_intrinsic_supported(id, is_virtual); >> + is_available = compiler != NULL && compiler->is_intrinsic_available(mh, C->directive()); >> + if (is_available && is_virtual) { >> + is_available = compiler->is_virtual_intrinsic_supported(id); >> + } >> >> Will it satisfy you? > > How many callers are there? From an API design perspective this method is either only for virtual intrinsics, so no parameter needed, or it is for general intrinsics and the parameter indicates what type. This is the only place where it is called. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Thu Mar 9 05:22:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 05:22:10 GMT Subject: RFR: 8281941: Change CDS warning messages to use Unified Logging In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:25:38 GMT, Matias Saavedra Silva wrote: > As an addendum to previous commits that changed CDS logging, this replaces the remaining log messages with Unified logging. There are also old warning messages that used to be prefixed with UseSharedSpaces which have been updated along with their tests. These changes seem fine in themselves. There are some inconsistencies, IMO, in the choice of log-level for CDS "failures" but that would be for a separate RFE. For example I find it odd that reporting an issue trying to load the shared archive is a warning, but the actual message the archive could not be used is only "info": [0.001s][warning][cds] Unable to read generic CDS file map header from shared archive [0.001s][info ][cds] Unable to use shared archive: invalid archive Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12890 From kvn at openjdk.org Thu Mar 9 05:24:07 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 05:24:07 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: <5tSsZG-Xkuz5KL0GfHdblkfBgLyi7jRHSeysdBS4Lp8=.17d07529-fa55-4b5d-ac70-7e485e470e85@github.com> Message-ID: On Thu, 9 Mar 2023 05:03:27 GMT, Vladimir Kozlov wrote: >> How many callers are there? From an API design perspective this method is either only for virtual intrinsics, so no parameter needed, or it is for general intrinsics and the parameter indicates what type. > > This is the only place where it is called. Actually I found that I don't need `is_virtual_intrinsic_supported()` because the same information provides existing [vmIntrinsics::does_virtual_dispatch(id)](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/vmIntrinsics.cpp#L173) ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 05:31:52 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 05:31:52 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: References: Message-ID: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12858/files - new: https://git.openjdk.org/jdk/pull/12858/files/43c0056b..2d6ff556 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=00-01 Stats: 28 lines in 4 files changed: 4 ins; 21 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12858.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12858/head:pull/12858 PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Thu Mar 9 05:33:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 05:33:48 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: References: Message-ID: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Update comment per @alanb ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12892/files - new: https://git.openjdk.org/jdk/pull/12892/files/6a145ee0..67246a74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12892.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12892/head:pull/12892 PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Thu Mar 9 05:37:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 05:37:11 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: <-rOdC_E6hYCpzF08mXks45wPRTfaKxFNas553VbqlZ4=.5da83163-9d77-486d-bb03-921c246d682b@github.com> References: <-rOdC_E6hYCpzF08mXks45wPRTfaKxFNas553VbqlZ4=.5da83163-9d77-486d-bb03-921c246d682b@github.com> Message-ID: On Tue, 7 Mar 2023 12:06:27 GMT, Alan Bateman wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > If I read this correctly, a JNI attaching thread has its JavaThread on the threads list, the j.l.Thread object is allocated but not yet initialized or the initialization fails (in both cases, holder is null). If a JVMTI agent gets a reference to the thread at this point (GetAllThreads, instrumented the constructor, several other ways) then functions such as GetThreadInfo will attempt to access fields and crash. > > The changes look okay to me except for SET_FIELDHOLDER_FIELD being a no-op when holder is null. It should be okay for a JVMTI agent to read a default value but if set_priority, set_daemon, or set_thread_status can be being called when the initialization fails then it suggests there the error handling might isn't complete somewhere. Thanks for the review @AlanBateman ! ------------- PR: https://git.openjdk.org/jdk/pull/12892 From kvn at openjdk.org Thu Mar 9 05:43:06 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 05:43:06 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: <14u458Y0fDM8iouM3LGbvnQZKw5FzRoVmgKchzOUpsk=.1abcb17b-53dd-4524-9942-be9e3ec6a358@github.com> References: <14u458Y0fDM8iouM3LGbvnQZKw5FzRoVmgKchzOUpsk=.1abcb17b-53dd-4524-9942-be9e3ec6a358@github.com> Message-ID: On Thu, 9 Mar 2023 02:34:34 GMT, David Holmes wrote: > I'm a bit confused about the core issue of "Add VM_Version::is_intrinsic_supported(id)" because AFAICS this was only added for x86 ?? Currently the only way to check in shared code if a platform supports intrinsic is to add new flag which is set in platform specific code based on CPU instructions set. And we have "ton" of such global flags already: [globals.hpp#L320](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L320) I don't want to add new flag for each new intrinsic. I propose to add new VM_Version method `is_intrinsic_supported(id)` which can be called from shared code. Currently only new `float16ToFloat` intrinsic does not corresponding flag for which I can use this new API. The intrinsic is implemented only on Aarch64 (unconditionally) and on x86 (if it has corresponding AVX512 or F16C instructions). Because of that currently we need to check `float16ToFloat` support only for x86. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 05:56:16 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 05:56:16 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 05:31:52 GMT, Vladimir Kozlov wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments An other approach, which I implemented in [JDK-8302976](https://git.openjdk.org/jdk/pull/12869), is to add intrinsic specific `VM_Version` method: [vm_version_x86.hpp#L762](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.hpp#L762) Then you have the same issue as with flags. You will have multiply such methods in a future. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Thu Mar 9 06:26:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 06:26:15 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: References: Message-ID: <8GoprkMChP1bYoO8PPNijDfhYgMtrD4UGuaHHTiRbZs=.12a42da9-b05f-497e-9c7e-616907aebe90@github.com> On Thu, 9 Mar 2023 05:31:52 GMT, Vladimir Kozlov wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments So are there plans to migrate to this new mechanism and remove those global flags? ------------- PR: https://git.openjdk.org/jdk/pull/12858 From kvn at openjdk.org Thu Mar 9 06:43:25 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 9 Mar 2023 06:43:25 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: <8GoprkMChP1bYoO8PPNijDfhYgMtrD4UGuaHHTiRbZs=.12a42da9-b05f-497e-9c7e-616907aebe90@github.com> References: <8GoprkMChP1bYoO8PPNijDfhYgMtrD4UGuaHHTiRbZs=.12a42da9-b05f-497e-9c7e-616907aebe90@github.com> Message-ID: On Thu, 9 Mar 2023 06:22:56 GMT, David Holmes wrote: > So are there plans to migrate to this new mechanism and remove those global flags? Good point. I filed RFE [JDK-8303864](https://bugs.openjdk.org/browse/JDK-8303864) ------------- PR: https://git.openjdk.org/jdk/pull/12858 From jrose at openjdk.org Thu Mar 9 07:27:16 2023 From: jrose at openjdk.org (John R Rose) Date: Thu, 9 Mar 2023 07:27:16 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 05:33:48 GMT, David Holmes wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update comment per @alanb Yes, that looks reasonable. The macro regularizes the necessary careful treatment of the extra indirection. I see how a previous one-off attempt probably left holes, which this systematic treatment would fill. Changing CHECK to THREAD is tolerable, since not much happens afterwards, just a statement or two. Maybe add a comment saying what could fail, and why that extra logic is still OK to run even if the failure happens. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From alanb at openjdk.org Thu Mar 9 07:51:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Mar 2023 07:51:08 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: References: Message-ID: <7k70tRd1q2zRo9fkLntvia_ADYBMB142e9fUaqDTv1U=.88d84e8f-fa04-4286-a9be-f5f1d19e4a3d@github.com> On Thu, 9 Mar 2023 05:33:48 GMT, David Holmes wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update comment per @alanb Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Thu Mar 9 07:51:09 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Mar 2023 07:51:09 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: References: Message-ID: <3SoYcTDayk_uMxKO0faUD5NjnfloOaoH8-UZ2e9Ufgc=.62578d53-cebd-45fb-bd57-d6cd1d91cc00@github.com> On Thu, 9 Mar 2023 07:23:50 GMT, John R Rose wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment per @alanb > > Yes, that looks reasonable. The macro regularizes the necessary careful treatment of the extra indirection. I see how a previous one-off attempt probably left holes, which this systematic treatment would fill. > > Changing CHECK to THREAD is tolerable, since not much happens afterwards, just a statement or two. Maybe add a comment saying what could fail, and why that extra logic is still OK to run even if the failure happens. Thanks for taking a look at this @rose00 . > Changing CHECK to THREAD is tolerable, since not much happens afterwards, just a statement or two. Maybe add a comment saying what could fail, and why that extra logic is still OK to run even if the failure happens. I've changed THREAD to CHECK so that we will skip the following statements. The call to `java_lang_Thread::set_daemon(thread_oop())` could assert due to the null FieldHolder. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From mbaesken at openjdk.org Thu Mar 9 10:32:45 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 9 Mar 2023 10:32:45 GMT Subject: RFR: JDK-8303822: gtestMain should give more helpful output Message-ID: When the JDK to test is not provided, gtestMain currently prints something like this : ./hotspot/variant-server/libjvm/gtest/gtestLauncher ERROR: You must specify a JDK to use for running the unit tests. The output could be improved, might be helpful for occasional users, e.g. `ERROR: You must specify a JDK (-jdk , --jdk= or -jdk:) to use for running the unit tests.` ------------- Commit messages: - JDK-8303822 Changes: https://git.openjdk.org/jdk/pull/12940/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303822 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12940.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12940/head:pull/12940 PR: https://git.openjdk.org/jdk/pull/12940 From jwaters at openjdk.org Thu Mar 9 11:36:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 9 Mar 2023 11:36:10 GMT Subject: RFR: 8303810: Move attribute of FileMapInfo::fail_stop to match JDK-8302124 [v2] In-Reply-To: References: Message-ID: > Cleanup of [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) to move an attribute missed in it to match the HotSpot Style Guide's required attribute position Julian Waters 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 'openjdk:master' into patch-8 - 8303810: Move attribute of FileMapInfo::fail_stop to match JDK-8302124 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12918/files - new: https://git.openjdk.org/jdk/pull/12918/files/2ad173da..e9083a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12918&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12918&range=00-01 Stats: 3187 lines in 105 files changed: 2446 ins; 435 del; 306 mod Patch: https://git.openjdk.org/jdk/pull/12918.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12918/head:pull/12918 PR: https://git.openjdk.org/jdk/pull/12918 From jwaters at openjdk.org Thu Mar 9 11:54:44 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 9 Mar 2023 11:54:44 GMT Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to match JDK-8302124 [v3] In-Reply-To: References: Message-ID: > [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: debug.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12918/files - new: https://git.openjdk.org/jdk/pull/12918/files/e9083a2e..359bccc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12918&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12918&range=01-02 Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12918.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12918/head:pull/12918 PR: https://git.openjdk.org/jdk/pull/12918 From dcubed at openjdk.org Thu Mar 9 16:17:22 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 9 Mar 2023 16:17:22 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: References: Message-ID: <3xsI0fDDT7ijOPyhRuS3UT5XBkff94pInL1vjnvjOSk=.6e9a4217-b7f0-4812-8993-8c078150a887@github.com> On Thu, 9 Mar 2023 05:33:48 GMT, David Holmes wrote: >> To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. >> >> The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. >> >> In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. >> >> Testing: tiers 1-3 as a sanity test >> >> There's no way to write a regression test for this. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update comment per @alanb Thumbs up. My only comments are nits. I like how much cleaner the code is now. src/hotspot/share/classfile/javaClasses.cpp line 1603: > 1601: > 1602: oop java_lang_Thread::holder(oop java_thread) { > 1603: // Note: may be null if the thread is still attaching nit perhaps: s/may be null/may return null/ src/hotspot/share/classfile/javaClasses.cpp line 1715: > 1713: JavaThread::current()->thread_state() == _thread_in_vm, > 1714: "Java Thread is not running in vm"); > 1715: GET_FIELDHOLDER_FIELD(java_thread, get_thread_status, JavaThreadStatus::NEW; /* not initialized */); I didn't expect to see a ';' after the 'NEW'. Should that be deleted? Should it have caused a compile error? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/12892 From kbarrett at openjdk.org Thu Mar 9 20:17:20 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 9 Mar 2023 20:17:20 GMT Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to match JDK-8302124 [v3] In-Reply-To: References: Message-ID: <8Ohq_fYWdoYmD7bvYKKFgIbc8L0SkFE5U22q9t2ylmE=.948ef550-ba01-4eb7-8b3d-3cd8a45cf4ae@github.com> On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters wrote: >> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > debug.hpp Please don't do this. This change will just make the redo harder by introducing merge conflicts. ------------- PR: https://git.openjdk.org/jdk/pull/12918 From fparain at openjdk.org Thu Mar 9 20:51:38 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 9 Mar 2023 20:51:38 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Wed, 8 Mar 2023 15:46:12 GMT, Coleen Phillimore wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > src/hotspot/share/classfile/classFileParser.cpp line 1491: > >> 1489: _temp_field_info = new GrowableArray(total_fields); >> 1490: >> 1491: ResourceMark rm(THREAD); > > Is the ResourceMark ok here or should it go before allocating _temp_field_info ? _temp_field_info must survive after ClassFileParser::parse_fields() has returned, so definitively after the allocation of _temp_field_info. That being said, I don't see any reason to have a ResourceMark here, probably a remain of some debugging/tracing code. I'll remove it. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From lmesnik at openjdk.org Thu Mar 9 20:54:57 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 9 Mar 2023 20:54:57 GMT Subject: RFR: JDK-8303822: gtestMain should give more helpful output In-Reply-To: References: Message-ID: <-U_IPDt8MAc6QoqskWCrqBbVJDprYMXAVHcj6YyIdnQ=.eaf7699e-61ab-407f-b7d5-eaba9b05c4d2@github.com> On Thu, 9 Mar 2023 10:23:53 GMT, Matthias Baesken wrote: > When the JDK to test is not provided, gtestMain currently prints something like this : > ./hotspot/variant-server/libjvm/gtest/gtestLauncher > ERROR: You must specify a JDK to use for running the unit tests. > > The output could be improved, might be helpful for occasional users, e.g. > `ERROR: You must specify a JDK (-jdk , --jdk= or -jdk:) to use for running the unit tests.` Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12940 From fparain at openjdk.org Thu Mar 9 21:02:05 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 9 Mar 2023 21:02:05 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 15:50:05 GMT, Coleen Phillimore wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > src/hotspot/share/classfile/classFileParser.cpp line 1608: > >> 1606: fflags.update_injected(true); >> 1607: AccessFlags aflags; >> 1608: FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags); > > I don't know why there's a cast here until I read more. If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead? The type of name_index and signature_index is const vmSymbolID, because they names and signatures of injected fields do not come from a constant pool, but from the vmSymbol array. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Thu Mar 9 21:12:11 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 9 Mar 2023 21:12:11 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: <0Ayok_tvKtFDl6deMwvAIUcT8MFkA8fIXSCHqwXKYts=.2cf55fae-34ae-4ce3-b733-b32df0acaf45@github.com> On Wed, 8 Mar 2023 16:05:57 GMT, Coleen Phillimore wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 554: > >> 552: FieldInfo ctrl = _field_info->at(0); >> 553: FieldGroup* group = nullptr; >> 554: FieldInfo tfi = *it; > > What's the 't' in tfi? Maybe a longer variable name would be helpful here. At some point there was a TempFieldInfo type, hence the name. Renamed to fieldinfo. > src/hotspot/share/classfile/javaClasses.cpp line 871: > >> 869: // a new UNSIGNED5 stream, and substitute it to the old FieldInfo stream. >> 870: >> 871: int java_fields; > > Can you put InstanceKlass* ik = InstanceKlass::cast(k); here and use that so there's only one cast? Sure, done. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From matsaave at openjdk.org Thu Mar 9 23:23:02 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 9 Mar 2023 23:23:02 GMT Subject: RFR: 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use Message-ID: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> The method `Arguments::get_default_shared_archive_path()` generates a string containing a path every time it is called. Since this method is idempotent, the string only needs to be constructed once in the lifetime of the VM. This change caches the result of `Arguments::get_default_shared_archive_path()` and ensures the path string is only generated once. ------------- Commit messages: - 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use Changes: https://git.openjdk.org/jdk/pull/12963/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303548 Stats: 21 lines in 3 files changed: 3 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/12963.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12963/head:pull/12963 PR: https://git.openjdk.org/jdk/pull/12963 From ccheung at openjdk.org Fri Mar 10 01:07:14 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 10 Mar 2023 01:07:14 GMT Subject: RFR: 8281941: Change CDS warning messages to use Unified Logging In-Reply-To: References: Message-ID: <9owpHij9aOZiOS58srPfQgCohomVE15xpWtd8Yx2OUY=.364e02c4-5f09-415d-80ea-cb25eaaf2870@github.com> On Mon, 6 Mar 2023 21:25:38 GMT, Matias Saavedra Silva wrote: > As an addendum to previous commits that changed CDS logging, this replaces the remaining log messages with Unified logging. There are also old warning messages that used to be prefixed with UseSharedSpaces which have been updated along with their tests. LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12890 From ccheung at openjdk.org Fri Mar 10 01:09:01 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 10 Mar 2023 01:09:01 GMT Subject: RFR: 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use In-Reply-To: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> References: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> Message-ID: On Thu, 9 Mar 2023 21:40:42 GMT, Matias Saavedra Silva wrote: > The method `Arguments::get_default_shared_archive_path()` generates a string containing a path every time it is called. Since this method is idempotent, the string only needs to be constructed once in the lifetime of the VM. This change caches the result of `Arguments::get_default_shared_archive_path()` and ensures the path string is only generated once. LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/12963 From kvn at openjdk.org Fri Mar 10 01:19:07 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 10 Mar 2023 01:19:07 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: <8GoprkMChP1bYoO8PPNijDfhYgMtrD4UGuaHHTiRbZs=.12a42da9-b05f-497e-9c7e-616907aebe90@github.com> References: <8GoprkMChP1bYoO8PPNijDfhYgMtrD4UGuaHHTiRbZs=.12a42da9-b05f-497e-9c7e-616907aebe90@github.com> Message-ID: On Thu, 9 Mar 2023 06:22:56 GMT, David Holmes wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > So are there plans to migrate to this new mechanism and remove those global flags? @dholmes-ora Do you have other questions? ------------- PR: https://git.openjdk.org/jdk/pull/12858 From manc at openjdk.org Fri Mar 10 02:20:59 2023 From: manc at openjdk.org (Man Cao) Date: Fri, 10 Mar 2023 02:20:59 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() Message-ID: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Hi all, Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. -Man ------------- Commit messages: - JDK-8303937: Corrupted heap dumps due to missing retries for os::write() Changes: https://git.openjdk.org/jdk/pull/12966/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12966&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303937 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12966.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12966/head:pull/12966 PR: https://git.openjdk.org/jdk/pull/12966 From dholmes at openjdk.org Fri Mar 10 02:33:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 02:33:12 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 9 Mar 2023 05:31:52 GMT, Vladimir Kozlov wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments No further questions :) Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12858 From cjplummer at openjdk.org Fri Mar 10 02:43:11 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Mar 2023 02:43:11 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Message-ID: <09d4_ZhXbBPbvCwWnMZI9JKKsDYtG5BSr1fagPJakaQ=.bb11aa7c-0df1-4d0f-b27c-8d8ed3bb0b91@github.com> On Fri, 10 Mar 2023 02:13:22 GMT, Man Cao wrote: > Hi all, > > Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. > > Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. > > -Man Looks good. What type of testing have you done? If you grep in the test directory for `HprofParser`, you can find the tests you should be running. You can ignore the sa tests. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12966 From kvn at openjdk.org Fri Mar 10 02:53:05 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 10 Mar 2023 02:53:05 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 05:31:52 GMT, Vladimir Kozlov wrote: >> Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. >> We have *product* VM flags for most intrinsics and set them in VM based on HW support. >> But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. >> Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. >> >> I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). >> >> Additional fixes: >> Fixed Interpreter to skip intrinsics if they are disabled with flag. >> Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. >> Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. >> Added missing `native` mark to `_currentThread`. >> Removed unused `AbstractInterpreter::in_native_entry()`. >> Cleanup C2 intrinsic checks code. >> >> Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Thank you, David. ------------- PR: https://git.openjdk.org/jdk/pull/12858 From dholmes at openjdk.org Fri Mar 10 02:57:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 02:57:10 GMT Subject: RFR: 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use In-Reply-To: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> References: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> Message-ID: On Thu, 9 Mar 2023 21:40:42 GMT, Matias Saavedra Silva wrote: > The method `Arguments::get_default_shared_archive_path()` generates a string containing a path every time it is called. Since this method is idempotent, the string only needs to be constructed once in the lifetime of the VM. This change caches the result of `Arguments::get_default_shared_archive_path()` and ensures the path string is only generated once. LGTM2 Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12963 From manc at openjdk.org Fri Mar 10 03:06:04 2023 From: manc at openjdk.org (Man Cao) Date: Fri, 10 Mar 2023 03:06:04 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <09d4_ZhXbBPbvCwWnMZI9JKKsDYtG5BSr1fagPJakaQ=.bb11aa7c-0df1-4d0f-b27c-8d8ed3bb0b91@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> <09d4_ZhXbBPbvCwWnMZI9JKKsDYtG5BSr1fagPJakaQ=.bb11aa7c-0df1-4d0f-b27c-8d8ed3bb0b91@github.com> Message-ID: On Fri, 10 Mar 2023 02:40:03 GMT, Chris Plummer wrote: > Looks good. What type of testing have you done? If you grep in the test directory for `HprofParser`, you can find the tests you should be running. You can ignore the sa tests. Thanks for quick review. I'm running tier1 and tier2 jtreg tests now, and the pre-submit is also running tier1 tests. I have tested with our internal application's integration test, which exposes the heap corruption and this change fixed it. However, I'm not sure how to write a jtreg test that exposes the heap corruption. We perhaps need to patch or mock write() syscall to make it return fewer bytes than the argument specifies. ------------- PR: https://git.openjdk.org/jdk/pull/12966 From dholmes at openjdk.org Fri Mar 10 03:06:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 03:06:57 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v4] In-Reply-To: References: Message-ID: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Dcubed comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12892/files - new: https://git.openjdk.org/jdk/pull/12892/files/67246a74..4a8884aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12892&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12892.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12892/head:pull/12892 PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Fri Mar 10 03:07:01 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 03:07:01 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: <3xsI0fDDT7ijOPyhRuS3UT5XBkff94pInL1vjnvjOSk=.6e9a4217-b7f0-4812-8993-8c078150a887@github.com> References: <3xsI0fDDT7ijOPyhRuS3UT5XBkff94pInL1vjnvjOSk=.6e9a4217-b7f0-4812-8993-8c078150a887@github.com> Message-ID: On Thu, 9 Mar 2023 16:00:33 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment per @alanb > > src/hotspot/share/classfile/javaClasses.cpp line 1603: > >> 1601: >> 1602: oop java_lang_Thread::holder(oop java_thread) { >> 1603: // Note: may be null if the thread is still attaching > > nit perhaps: s/may be null/may return null/ Changed ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Fri Mar 10 03:12:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 03:12:14 GMT Subject: RFR: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads [v3] In-Reply-To: <3xsI0fDDT7ijOPyhRuS3UT5XBkff94pInL1vjnvjOSk=.6e9a4217-b7f0-4812-8993-8c078150a887@github.com> References: <3xsI0fDDT7ijOPyhRuS3UT5XBkff94pInL1vjnvjOSk=.6e9a4217-b7f0-4812-8993-8c078150a887@github.com> Message-ID: <-Gxysp4ppFp3grAfafWSugMQ3wvGOuj1qd5Ug198UdA=.3e914773-7123-4d5a-ae2c-42cf1bd59145@github.com> On Thu, 9 Mar 2023 16:13:53 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment per @alanb > > Thumbs up. My only comments are nits. > > I like how much cleaner the code is now. That for the review @dcubed-ojdk ! > src/hotspot/share/classfile/javaClasses.cpp line 1715: > >> 1713: JavaThread::current()->thread_state() == _thread_in_vm, >> 1714: "Java Thread is not running in vm"); >> 1715: GET_FIELDHOLDER_FIELD(java_thread, get_thread_status, JavaThreadStatus::NEW; /* not initialized */); > > I didn't expect to see a ';' after the 'NEW'. Should that be deleted? > Should it have caused a compile error? Well spotted. It isn't wanted but doesn't cause an error - not sure why not as it is an unreachable empty statement. Anyway it is fixed. ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Fri Mar 10 03:12:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 03:12:16 GMT Subject: Integrated: 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads In-Reply-To: References: Message-ID: <40Wlggy5UeN2sHSHmobOzs624jIsx2UbFbltqoEbqVg=.0b813347-e4d2-41ae-9b29-b1078bfb38fc@github.com> On Mon, 6 Mar 2023 21:52:47 GMT, David Holmes wrote: > To support virtual threads a number of fields were moved out of `java.lang.Thread` into a separate `FieldHolder` object. The VM was updated to then access certain thread fields via the `FieldHolder`. > > The code for attaching a thread to the VM, specifically `allocate_threadObj` didn't allow for the `Thread` constructor throwing an exception, and so failing to allocate the `FieldHolder` before attempting to access a field through the `FieldHolder`. This resulted in assertion failures in `javaClasses.cpp` (or crashes in a product build). That code is fixed to ensure we cease processing if the constructor throws an exception. > > In addition, we need to recognise that whilst a native thread is attaching via JNI, it is partially initialized (to varying degrees) but also visible through JVMTI. Though the window is small JVMTI could get hold of an attaching thread and then invoke methods that would try to access uninitialized state. When this was state of `Thread` instance there was no problem as the object existed in its zero-initialized form (it had been allocated directly but no constructor run). However, anythng accessed via the `FieldHolder` is now a problem as the `FieldHolder` may not exist. So we modify all of the `FieldHolder` get/set methods to account for it being null: setters will do nothing, while getters return the default zero value for the field. > > Testing: tiers 1-3 as a sanity test > > There's no way to write a regression test for this. > > Thanks. This pull request has now been integrated. Changeset: e26cc526 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e26cc526006b16765510e72bd085de069dfae419 Stats: 63 lines in 3 files changed: 26 ins; 21 del; 16 mod 8303624: The java.lang.Thread.FieldHolder can be null for JNI attaching threads Reviewed-by: alanb, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/12892 From dholmes at openjdk.org Fri Mar 10 03:24:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 03:24:06 GMT Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to match JDK-8302124 [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters wrote: >> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > debug.hpp I agree with Kim. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12918 From cjplummer at openjdk.org Fri Mar 10 03:50:10 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 10 Mar 2023 03:50:10 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Message-ID: On Fri, 10 Mar 2023 02:13:22 GMT, Man Cao wrote: > Hi all, > > Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. > > Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. > > -Man I don't think tier1 and tier2 testing will catch the following two tests. You should run them manually: test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java test/jdk/sun/tools/jmap/BasicJMapTest.java ------------- PR: https://git.openjdk.org/jdk/pull/12966 From dholmes at openjdk.org Fri Mar 10 05:11:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Mar 2023 05:11:08 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Message-ID: <7y5IoIzwvqXrktfWsAt8p4ZNzngwNqVgriciajphg4Q=.c92f8267-d145-4b13-b643-eeb80717d0d3@github.com> On Fri, 10 Mar 2023 02:13:22 GMT, Man Cao wrote: > Hi all, > > Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. > > Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. > > -Man Good catch! There are other users of os::write that also do not allow for short writes - I will file bugs for those. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12966 From manc at openjdk.org Fri Mar 10 06:59:15 2023 From: manc at openjdk.org (Man Cao) Date: Fri, 10 Mar 2023 06:59:15 GMT Subject: RFR: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Message-ID: On Fri, 10 Mar 2023 02:13:22 GMT, Man Cao wrote: > Hi all, > > Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. > > Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. > > -Man Thanks for the reviews and feedback. > I don't think tier1 and tier2 testing will catch the following two tests. You should run them manually: > > test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java test/jdk/sun/tools/jmap/BasicJMapTest.java Tier1, tier2 finished and I manually ran these two tests. All passed. Will integrate tomorrow morning PST. ------------- PR: https://git.openjdk.org/jdk/pull/12966 From mbaesken at openjdk.org Fri Mar 10 08:30:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Mar 2023 08:30:15 GMT Subject: RFR: JDK-8303822: gtestMain should give more helpful output In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 10:23:53 GMT, Matthias Baesken wrote: > When the JDK to test is not provided, gtestMain currently prints something like this : > ./hotspot/variant-server/libjvm/gtest/gtestLauncher > ERROR: You must specify a JDK to use for running the unit tests. > > The output could be improved, might be helpful for occasional users, e.g. > `ERROR: You must specify a JDK (-jdk , --jdk= or -jdk:) to use for running the unit tests.` Hi Leonid, thanks for the review ! ------------- PR: https://git.openjdk.org/jdk/pull/12940 From mbaesken at openjdk.org Fri Mar 10 08:30:16 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Mar 2023 08:30:16 GMT Subject: Integrated: JDK-8303822: gtestMain should give more helpful output In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 10:23:53 GMT, Matthias Baesken wrote: > When the JDK to test is not provided, gtestMain currently prints something like this : > ./hotspot/variant-server/libjvm/gtest/gtestLauncher > ERROR: You must specify a JDK to use for running the unit tests. > > The output could be improved, might be helpful for occasional users, e.g. > `ERROR: You must specify a JDK (-jdk , --jdk= or -jdk:) to use for running the unit tests.` This pull request has now been integrated. Changeset: 0f26d09d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/0f26d09da881b1dfedfc0dcaff46fc169fa1f020 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8303822: gtestMain should give more helpful output Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/12940 From duke at openjdk.org Fri Mar 10 08:31:19 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 10 Mar 2023 08:31:19 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings Message-ID: To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). Briefly: 1. An instance of `Cleaner` (`java.lang.ref`) is created. 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). 3. Write code in the callback to do other cleanings. 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. Cleaner c = new Cleaner(); Cleanable cleanable = c.register(an_obj, a_runnable); ... //JVM notifies by calling the a_runnable.run() {...} ... // possible to explicit cleaning cleanable.clean(an_obj); ------------- Commit messages: - 8301684: Fix test code to not get finalizer deprecation warnings Changes: https://git.openjdk.org/jdk/pull/12968/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12968&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301684 Stats: 109 lines in 2 files changed: 61 ins; 41 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12968/head:pull/12968 PR: https://git.openjdk.org/jdk/pull/12968 From duke at openjdk.org Fri Mar 10 09:40:11 2023 From: duke at openjdk.org (Varada M) Date: Fri, 10 Mar 2023 09:40:11 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. Message-ID: When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. This bug can be fixed by retrieving the pattern [peekFirst()] instead of removing the pattern [pollFirst()] and remove the pattern only if the pattern is matching [deque.remove(Pattern)] . JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) ------------- Commit messages: - HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern Changes: https://git.openjdk.org/jdk/pull/12970/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12970&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303948 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12970.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12970/head:pull/12970 PR: https://git.openjdk.org/jdk/pull/12970 From coleenp at openjdk.org Fri Mar 10 12:52:14 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 10 Mar 2023 12:52:14 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 08:23:45 GMT, Afshin Zafari wrote: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > ... > // possible to explicit cleaning > cleanable.clean(an_obj); > > ### Tests > local: vmTestbase/nsk/monitoring/stress/classload > mach5: tier 1-5 I don't know how cleaners work so here are some superficial comments. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 102: > 100: * Here it will be used for tracking the local instance of 'CustomClassLoader'. > 101: */ > 102: private static class CustomClassLoaderCleaner implements Runnable{ nit: can you add a space before open { in these lines? Also use // comments ? test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 318: > 316: > 317: // Since customClassLoader object is set to null, we should also null the cleaning > 318: // objbects to let them be created when new customClassLoader is created. typo: objbects ------------- PR: https://git.openjdk.org/jdk/pull/12968 From coleenp at openjdk.org Fri Mar 10 13:49:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 10 Mar 2023 13:49:37 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders Message-ID: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 Tested with tier1-7. ------------- Commit messages: - 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders Changes: https://git.openjdk.org/jdk/pull/12974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12974&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298469 Stats: 163 lines in 10 files changed: 1 ins; 147 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/12974.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12974/head:pull/12974 PR: https://git.openjdk.org/jdk/pull/12974 From matsaave at openjdk.org Fri Mar 10 14:41:12 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 10 Mar 2023 14:41:12 GMT Subject: RFR: 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use In-Reply-To: References: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> Message-ID: On Fri, 10 Mar 2023 02:54:43 GMT, David Holmes wrote: >> The method `Arguments::get_default_shared_archive_path()` generates a string containing a path every time it is called. Since this method is idempotent, the string only needs to be constructed once in the lifetime of the VM. This change caches the result of `Arguments::get_default_shared_archive_path()` and ensures the path string is only generated once. > > LGTM2 > > Thanks Thank you @dholmes-ora and @calvinccheung! ------------- PR: https://git.openjdk.org/jdk/pull/12963 From matsaave at openjdk.org Fri Mar 10 14:42:15 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 10 Mar 2023 14:42:15 GMT Subject: RFR: 8281941: Change CDS warning messages to use Unified Logging In-Reply-To: <9owpHij9aOZiOS58srPfQgCohomVE15xpWtd8Yx2OUY=.364e02c4-5f09-415d-80ea-cb25eaaf2870@github.com> References: <9owpHij9aOZiOS58srPfQgCohomVE15xpWtd8Yx2OUY=.364e02c4-5f09-415d-80ea-cb25eaaf2870@github.com> Message-ID: On Fri, 10 Mar 2023 01:03:50 GMT, Calvin Cheung wrote: >> As an addendum to previous commits that changed CDS logging, this replaces the remaining log messages with Unified logging. There are also old warning messages that used to be prefixed with UseSharedSpaces which have been updated along with their tests. > > LGTM Thank you for the reviews @calvinccheung and @dholmes-ora. ------------- PR: https://git.openjdk.org/jdk/pull/12890 From fparain at openjdk.org Fri Mar 10 15:31:16 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 10 Mar 2023 15:31:16 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 16:25:07 GMT, Coleen Phillimore wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > src/hotspot/share/oops/fieldStreams.hpp line 104: > >> 102: AccessFlags flags; >> 103: flags.set_flags(field()->access_flags()); >> 104: return flags; > > Did this used to do this for a reason? Using the setter rather than the constructor filters out the VM defined flags and keeps only the flags from the class file. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From matsaave at openjdk.org Fri Mar 10 16:34:25 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 10 Mar 2023 16:34:25 GMT Subject: Integrated: 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use In-Reply-To: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> References: <5rdXyr613W9qq8uR3oSZW9kZ0F2Aa-33Mji8YyWLGDo=.6cc660c7-9c1a-4285-89c4-b1529a0d520d@github.com> Message-ID: On Thu, 9 Mar 2023 21:40:42 GMT, Matias Saavedra Silva wrote: > The method `Arguments::get_default_shared_archive_path()` generates a string containing a path every time it is called. Since this method is idempotent, the string only needs to be constructed once in the lifetime of the VM. This change caches the result of `Arguments::get_default_shared_archive_path()` and ensures the path string is only generated once. This pull request has now been integrated. Changeset: 548d552b Author: Matias Saavedra Silva Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/548d552bc10a3031fc85724ef561d17878dda5b1 Stats: 21 lines in 3 files changed: 3 ins; 3 del; 15 mod 8303548: Arguments::get_default_shared_archive_path() should cache the result for future use Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12963 From matsaave at openjdk.org Fri Mar 10 16:35:25 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 10 Mar 2023 16:35:25 GMT Subject: Integrated: 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:15:56 GMT, Matias Saavedra Silva wrote: > The path parameter is no longer used in the method `ClassLoader::add_to_app_classpath_entries` so it can be safely removed. Verified with tier 1-4 tests. This pull request has now been integrated. Changeset: c26e1d01 Author: Matias Saavedra Silva Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/c26e1d0148de27d0b257ec10380a5c50483fd3c0 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 8303495: Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...) Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12889 From matsaave at openjdk.org Fri Mar 10 17:15:24 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 10 Mar 2023 17:15:24 GMT Subject: Integrated: 8281941: Change CDS warning messages to use Unified Logging In-Reply-To: References: Message-ID: On Mon, 6 Mar 2023 21:25:38 GMT, Matias Saavedra Silva wrote: > As an addendum to previous commits that changed CDS logging, this replaces the remaining log messages with Unified logging. There are also old warning messages that used to be prefixed with UseSharedSpaces which have been updated along with their tests. This pull request has now been integrated. Changeset: 206661d4 Author: Matias Saavedra Silva Committer: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/206661d45f465399bd6e3c4066896fc822340b9f Stats: 17 lines in 7 files changed: 0 ins; 0 del; 17 mod 8281941: Change CDS warning messages to use Unified Logging Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/12890 From manc at openjdk.org Fri Mar 10 18:17:28 2023 From: manc at openjdk.org (Man Cao) Date: Fri, 10 Mar 2023 18:17:28 GMT Subject: Integrated: 8303937: Corrupted heap dumps due to missing retries for os::write() In-Reply-To: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> References: <-blsoQ0sSRBuqyRmlSNJN9Ba6qVoRbUpyJTBBI3fUlc=.9b54eeb0-0cce-4bab-b0f6-8fc4bedb20cb@github.com> Message-ID: On Fri, 10 Mar 2023 02:13:22 GMT, Man Cao wrote: > Hi all, > > Could anyone review this fix for heap dump corruption? See https://bugs.openjdk.org/browse/JDK-8303937 for more details. > > Our users reported frequent heap dump corruptions after updating to 11.0.14.1u. We found the root cause is changes from https://bugs.openjdk.org/browse/JDK-8237354. > > -Man This pull request has now been integrated. Changeset: bf16b5b9 Author: Man Cao URL: https://git.openjdk.org/jdk/commit/bf16b5b9880eb89b283006db090dce4346aa877b Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8303937: Corrupted heap dumps due to missing retries for os::write() Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12966 From dcubed at openjdk.org Fri Mar 10 20:14:26 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 10 Mar 2023 20:14:26 GMT Subject: Integrated: 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode Message-ID: A trivial fix to ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in -Xcomp mode ------------- Commit messages: - 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode Changes: https://git.openjdk.org/jdk/pull/12983/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12983&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304005 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12983.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12983/head:pull/12983 PR: https://git.openjdk.org/jdk/pull/12983 From rriggs at openjdk.org Fri Mar 10 20:14:27 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Mar 2023 20:14:27 GMT Subject: Integrated: 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in -Xcomp mode Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12983 From dcubed at openjdk.org Fri Mar 10 20:14:28 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 10 Mar 2023 20:14:28 GMT Subject: Integrated: 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 20:01:43 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in -Xcomp mode > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the fast review. ------------- PR: https://git.openjdk.org/jdk/pull/12983 From dcubed at openjdk.org Fri Mar 10 20:14:30 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 10 Mar 2023 20:14:30 GMT Subject: Integrated: 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in -Xcomp mode This pull request has now been integrated. Changeset: d7f4221b Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/d7f4221bfe9637a7961f30a25196a0e3161baafd Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8304005: ProblemList serviceability/AsyncGetCallTrace/MyPackage/ASGCTBaseTest.java on linux-x64 in Xcomp mode Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/12983 From aturbanov at openjdk.org Sat Mar 11 07:49:21 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 11 Mar 2023 07:49:21 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 08:23:45 GMT, Afshin Zafari wrote: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > ... > // possible to explicit cleaning > cleanable.clean(an_obj); > > ### Tests > local: vmTestbase/nsk/monitoring/stress/classload > mach5: tier 1-5 test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 114: > 112: @Override > 113: public void run(){ > 114: if(class_unloader != null){ Suggestion: if (class_unloader != null){ ------------- PR: https://git.openjdk.org/jdk/pull/12968 From jwaters at openjdk.org Sat Mar 11 14:40:31 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 11 Mar 2023 14:40:31 GMT Subject: RFR: 8303810: Restore attribute positions after JDK-8303839 to match JDK-8302124 [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 11:54:44 GMT, Julian Waters wrote: >> [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > debug.hpp Alright ------------- PR: https://git.openjdk.org/jdk/pull/12918 From jwaters at openjdk.org Sat Mar 11 14:40:33 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 11 Mar 2023 14:40:33 GMT Subject: Withdrawn: 8303810: Restore attribute positions after JDK-8303839 to match JDK-8302124 In-Reply-To: References: Message-ID: <6nQIo08AWqpAXCLVOr30cO8O5FtizMZc7sp8fu94TRY=.c85be9a6-ba66-49d5-ad89-77e7d60cc936@github.com> On Wed, 8 Mar 2023 08:39:08 GMT, Julian Waters wrote: > [JDK-8303839](https://bugs.openjdk.org/browse/JDK-8303839)'s revert of [[noreturn]] attributes also moved their already existing attributes back to behind their corresponding methods, they should be restored to where [JDK-8302124](https://bugs.openjdk.org/browse/JDK-8302124) requires them to be. Also fixes attribute from [JDK-8292269](https://bugs.openjdk.org/browse/JDK-8292269) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12918 From dcubed at openjdk.org Sat Mar 11 17:28:13 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 11 Mar 2023 17:28:13 GMT Subject: RFR: 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode Message-ID: Trivial fixes to ProblemList 3 different tests: [JDK-8304017](https://bugs.openjdk.org/browse/JDK-8304017) ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode [JDK-8304018](https://bugs.openjdk.org/browse/JDK-8304018) ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 [JDK-8304019](https://bugs.openjdk.org/browse/JDK-8304019) ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 ------------- Commit messages: - 8304019: ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 - 8304018: ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 - 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode Changes: https://git.openjdk.org/jdk/pull/12990/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12990&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304017 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12990.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12990/head:pull/12990 PR: https://git.openjdk.org/jdk/pull/12990 From stuefe at openjdk.org Sat Mar 11 17:37:20 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 11 Mar 2023 17:37:20 GMT Subject: RFR: 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 17:16:46 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList 3 different tests: > [JDK-8304017](https://bugs.openjdk.org/browse/JDK-8304017) ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode > [JDK-8304018](https://bugs.openjdk.org/browse/JDK-8304018) ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 > [JDK-8304019](https://bugs.openjdk.org/browse/JDK-8304019) ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 Looks good and trivial ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12990 From dcubed at openjdk.org Sat Mar 11 17:41:29 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 11 Mar 2023 17:41:29 GMT Subject: RFR: 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 17:34:05 GMT, Thomas Stuefe wrote: >> Trivial fixes to ProblemList 3 different tests: >> [JDK-8304017](https://bugs.openjdk.org/browse/JDK-8304017) ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode >> [JDK-8304018](https://bugs.openjdk.org/browse/JDK-8304018) ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 >> [JDK-8304019](https://bugs.openjdk.org/browse/JDK-8304019) ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 > > Looks good and trivial @tstuefe - Thanks for the fast review and especially on a Saturday! ------------- PR: https://git.openjdk.org/jdk/pull/12990 From dcubed at openjdk.org Sat Mar 11 17:41:30 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 11 Mar 2023 17:41:30 GMT Subject: Integrated: 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 17:16:46 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList 3 different tests: > [JDK-8304017](https://bugs.openjdk.org/browse/JDK-8304017) ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode > [JDK-8304018](https://bugs.openjdk.org/browse/JDK-8304018) ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 > [JDK-8304019](https://bugs.openjdk.org/browse/JDK-8304019) ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 This pull request has now been integrated. Changeset: fbc76c2c Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/fbc76c2c7866204783803d2ac829fb95b040a015 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod 8304017: ProblemList com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode 8304018: ProblemList javax/swing/JColorChooser/Test6827032.java on windows-x64 8304019: ProblemList java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java on windows-x64 Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/12990 From dholmes at openjdk.org Mon Mar 13 02:28:25 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 02:28:25 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> Message-ID: <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> On Fri, 10 Mar 2023 13:41:15 GMT, Coleen Phillimore wrote: > This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 > and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 > > Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 > > Tested with tier1-7. A couple of queries below. Not all the changes are obvious. Thanks. src/hotspot/share/classfile/placeholders.cpp line 137: > 135: assert(action != PlaceholderTable::LOAD_INSTANCE || !EnableWaitForParallelLoad || seen == nullptr, > 136: "Only one LOAD_INSTANCE allowed at a time"); > 137: Getting rid of the full assertion seems to go beyond obsoleting EnableWaitForParallelLoad. src/hotspot/share/classfile/systemDictionary.cpp line 564: > 562: > 563: // For bootstrap and non-parallelCapable class loaders, check and wait for > 564: // another thread to complete loading this class. A replacement comment describing the method would be nice. src/hotspot/share/classfile/systemDictionary.cpp line 604: > 602: } else { > 603: return nullptr; > 604: } Again unclear how this all disappears just because the flag is obsoleted. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From dholmes at openjdk.org Mon Mar 13 03:07:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 03:07:21 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 08:23:45 GMT, Afshin Zafari wrote: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > ... > // possible to explicit cleaning > cleanable.clean(an_obj); > > ### Tests > local: vmTestbase/nsk/monitoring/stress/classload > mach5: tier 1-5 This does not look quite right me - see comments below. You need to know that the Custom loader has become unreachable and only then check the unloaded classes. There are numerous references to finalization still in the code that should be updated to a more suitable form. I think things can be simplified/streamlined somewhat. Thanks test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 123: > 121: * The cleaner instance whose run() will be called by JVM. > 122: */ > 123: private CustomClassLoaderCleaner customCleaner; Not clear you actually need to store this, or cleaner or cleanable. The cleaner registration can just use locally defined objects. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 126: > 124: > 125: /** > 126: * The java.lanf.ref.Cleaner object for registering the cleaner and the object to be traced. typo: lanf test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 357: > 355: GarbageUtils.eatMemory(stresser, 50, 1024, 2); > 356: if (cleanable != null) { > 357: cleanable.clean(); This is wrong. You want the GC to cause the Cleaner to be processed indicating that the CustomClassLoader (and hence the classes it loaded) is actually unreachable and so the classes can be unloaded. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12968 From dholmes at openjdk.org Mon Mar 13 03:07:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 03:07:23 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 12:45:59 GMT, Coleen Phillimore wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> ... >> // possible to explicit cleaning >> cleanable.clean(an_obj); >> >> ### Tests >> local: vmTestbase/nsk/monitoring/stress/classload >> mach5: tier 1-5 > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 102: > >> 100: * Here it will be used for tracking the local instance of 'CustomClassLoader'. >> 101: */ >> 102: private static class CustomClassLoaderCleaner implements Runnable{ > > nit: can you add a space before open { in these lines? > Also use // comments ? Just to be clear there should be a space before all opening braces in all the changes. ------------- PR: https://git.openjdk.org/jdk/pull/12968 From dholmes at openjdk.org Mon Mar 13 03:07:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 03:07:24 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 02:31:49 GMT, David Holmes wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 102: >> >>> 100: * Here it will be used for tracking the local instance of 'CustomClassLoader'. >>> 101: */ >>> 102: private static class CustomClassLoaderCleaner implements Runnable{ >> >> nit: can you add a space before open { in these lines? >> Also use // comments ? > > Just to be clear there should be a space before all opening braces in all the changes. If you really need this class (not sure you do) then make it non-static so that it is always associated with its enclosing `ClassUnloader` instance, which can never be null. ------------- PR: https://git.openjdk.org/jdk/pull/12968 From dholmes at openjdk.org Mon Mar 13 03:07:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 03:07:27 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: On Sat, 11 Mar 2023 07:46:36 GMT, Andrey Turbanov wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> ... >> // possible to explicit cleaning >> cleanable.clean(an_obj); >> >> ### Tests >> local: vmTestbase/nsk/monitoring/stress/classload >> mach5: tier 1-5 > > test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 114: > >> 112: @Override >> 113: public void run(){ >> 114: if(class_unloader != null){ > > Suggestion: > > if (class_unloader != null){ BTW you don't need a null check here - this is your test code, nothing else is going to use it with null. ------------- PR: https://git.openjdk.org/jdk/pull/12968 From dholmes at openjdk.org Mon Mar 13 05:52:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Mar 2023 05:52:24 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 09:33:10 GMT, Varada M wrote: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) This fix seems correct - thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12970 From duke at openjdk.org Mon Mar 13 06:05:22 2023 From: duke at openjdk.org (Varada M) Date: Mon, 13 Mar 2023 06:05:22 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 05:49:27 GMT, David Holmes wrote: > This fix seems correct - thanks. Thanks @dholmes-ora for reviewing the changes. ------------- PR: https://git.openjdk.org/jdk/pull/12970 From mbaesken at openjdk.org Mon Mar 13 11:44:19 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Mar 2023 11:44:19 GMT Subject: RFR: JDK-8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so Message-ID: The test fails with [dwarf] ##### Find filename and line number for offset 0x000096a8 in library /lib64/glibc-hwcaps/power9/libpthread-2.28.so ##### [dwarf] Failed to load DWARF file for library /lib64/glibc-hwcaps/power9/libpthread-2.28.so or find DWARF sections directly inside it. and in stderr java.lang.RuntimeException: Must find library in "C [libpthread-2.28.so+0x96a8] start_thread+0xf8": expected true, was false Looks like the '-' in the lib-name libpthread-2.28.so is currently not allowed in the pattern of the test. This is similar to [JDK-8293201](https://bugs.openjdk.org/browse/JDK-8293201) . ------------- Commit messages: - JDK-8303973 Changes: https://git.openjdk.org/jdk/pull/12998/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12998&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303973 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12998.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12998/head:pull/12998 PR: https://git.openjdk.org/jdk/pull/12998 From chagedorn at openjdk.org Mon Mar 13 11:58:18 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 13 Mar 2023 11:58:18 GMT Subject: RFR: JDK-8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 11:37:27 GMT, Matthias Baesken wrote: > The test fails with > > [dwarf] ##### Find filename and line number for offset 0x000096a8 in library /lib64/glibc-hwcaps/power9/libpthread-2.28.so ##### > [dwarf] Failed to load DWARF file for library /lib64/glibc-hwcaps/power9/libpthread-2.28.so or find DWARF sections directly inside it. > > and in stderr > > java.lang.RuntimeException: Must find library in "C [libpthread-2.28.so+0x96a8] start_thread+0xf8": expected true, was false > > Looks like the '-' in the lib-name libpthread-2.28.so is currently not allowed in the pattern of the test. This is similar to [JDK-8293201](https://bugs.openjdk.org/browse/JDK-8293201) . Looks good and trivial! ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12998 From fparain at openjdk.org Mon Mar 13 12:09:10 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 12:09:10 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v2] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Addressing comments from first reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12855/files - new: https://git.openjdk.org/jdk/pull/12855/files/42a4d6a0..ce1180ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=00-01 Stats: 111 lines in 13 files changed: 40 ins; 22 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From mbaesken at openjdk.org Mon Mar 13 12:43:22 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Mar 2023 12:43:22 GMT Subject: RFR: JDK-8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so In-Reply-To: References: Message-ID: <0VmPF1CsDuN_F3zwjzPxcKkJ9J1p3JiSB2cHtTkKYs4=.c29148b2-7f42-48c2-9010-e44a95fbe3c8@github.com> On Mon, 13 Mar 2023 11:55:06 GMT, Christian Hagedorn wrote: > Looks good and trivial! Hi Christian, thanks for the review ! One question - maybe you have an opinion on that, should we use backslashes on the '-' , because it could be mistaken with a pattern-range ? ------------- PR: https://git.openjdk.org/jdk/pull/12998 From chagedorn at openjdk.org Mon Mar 13 13:02:29 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 13 Mar 2023 13:02:29 GMT Subject: RFR: JDK-8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 11:37:27 GMT, Matthias Baesken wrote: > The test fails with > > [dwarf] ##### Find filename and line number for offset 0x000096a8 in library /lib64/glibc-hwcaps/power9/libpthread-2.28.so ##### > [dwarf] Failed to load DWARF file for library /lib64/glibc-hwcaps/power9/libpthread-2.28.so or find DWARF sections directly inside it. > > and in stderr > > java.lang.RuntimeException: Must find library in "C [libpthread-2.28.so+0x96a8] start_thread+0xf8": expected true, was false > > Looks like the '-' in the lib-name libpthread-2.28.so is currently not allowed in the pattern of the test. This is similar to [JDK-8293201](https://bugs.openjdk.org/browse/JDK-8293201) . I don't have a strong opinion there - I guess both is acceptable. ------------- PR: https://git.openjdk.org/jdk/pull/12998 From coleenp at openjdk.org Mon Mar 13 13:57:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Mar 2023 13:57:42 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> Message-ID: On Mon, 13 Mar 2023 02:14:22 GMT, David Holmes wrote: >> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 >> and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 >> >> Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 >> >> Tested with tier1-7. > > src/hotspot/share/classfile/placeholders.cpp line 137: > >> 135: assert(action != PlaceholderTable::LOAD_INSTANCE || !EnableWaitForParallelLoad || seen == nullptr, >> 136: "Only one LOAD_INSTANCE allowed at a time"); >> 137: > > Getting rid of the full assertion seems to go beyond obsoleting EnableWaitForParallelLoad. The assertion reduces to something somewhat useless. Without EnableWaitForParallel load, you can have more then one thread with a LOAD_INSTANCE placeholder. These threads will wait when the go call into ClassLoader.loadClass() now. There is nothing to assert here anymore. > src/hotspot/share/classfile/systemDictionary.cpp line 564: > >> 562: >> 563: // For bootstrap and non-parallelCapable class loaders, check and wait for >> 564: // another thread to complete loading this class. > > A replacement comment describing the method would be nice. Ok, how about // Check for other threads loading this class either to throw CCE or wait in the case of the boot loader. > src/hotspot/share/classfile/systemDictionary.cpp line 604: > >> 602: } else { >> 603: return nullptr; >> 604: } > > Again unclear how this all disappears just because the flag is obsoleted. Only the bootclass loader waits on the SystemDictionary_lock for multiple threads now. Not the non-parallel capable class loaders. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From jcking at openjdk.org Mon Mar 13 15:26:44 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 13 Mar 2023 15:26:44 GMT Subject: RFR: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg [v2] In-Reply-To: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> References: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> Message-ID: <9DXr6-AnOqx5wLNN04XmVJcRghZMQ6czHBAdolRqQuA=.36242ad2-7a3f-4a03-bcb2-41a25182c943@github.com> On Fri, 3 Mar 2023 22:31:54 GMT, Justin King wrote: >> Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add missing const_cast > > Signed-off-by: Justin King Friendly poke for a second reviewer. :) ------------- PR: https://git.openjdk.org/jdk/pull/12867 From fparain at openjdk.org Mon Mar 13 16:03:26 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 16:03:26 GMT Subject: RFR: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg [v2] In-Reply-To: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> References: <0yOCcmKY8e9gesQkasuXaK-3X6dBv9Pb2vzmNA9Qs-g=.a2bf0933-fc74-4001-b8b9-232a4f668c79@github.com> Message-ID: On Fri, 3 Mar 2023 22:31:54 GMT, Justin King wrote: >> Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Add missing const_cast > > Signed-off-by: Justin King Looks good to me. ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/12867 From fparain at openjdk.org Mon Mar 13 16:26:06 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 16:26:06 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: SA additional caching from Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12855/files - new: https://git.openjdk.org/jdk/pull/12855/files/ce1180ef..322b626d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=01-02 Stats: 78 lines in 2 files changed: 35 ins; 34 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From jcking at openjdk.org Mon Mar 13 16:26:46 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 13 Mar 2023 16:26:46 GMT Subject: Integrated: JDK-8303606: Memory leaks in Arguments::parse_each_vm_init_arg In-Reply-To: References: Message-ID: <9C8_rJZIWwhRbUEHDFhTM59Ai7Lv1RkCxOYHoPwGNTI=.bed22853-5776-46ed-b0aa-406ebfa4cb37@github.com> On Fri, 3 Mar 2023 19:54:28 GMT, Justin King wrote: > Addresses various memory leaks identified by LSan related to Arguments::parse_each_vm_init_arg. This pull request has now been integrated. Changeset: 671a4521 Author: Justin King URL: https://git.openjdk.org/jdk/commit/671a45219fd727f2a0e1ed040577ec726775f07e Stats: 17 lines in 2 files changed: 10 ins; 0 del; 7 mod 8303606: Memory leaks in Arguments::parse_each_vm_init_arg Reviewed-by: dholmes, fparain ------------- PR: https://git.openjdk.org/jdk/pull/12867 From coleenp at openjdk.org Mon Mar 13 16:51:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Mar 2023 16:51:20 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 16:26:06 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > SA additional caching from Chris Plummer Most minor comments but one .inline.hpp still in an hpp file. I should point out that I only skimmed the SA and JVMCI changes. src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 2653: > 2651: } > 2652: InstanceKlass* iklass = InstanceKlass::cast(klass); > 2653: if (index < 0 ||index > iklass->total_fields_count()) { nit: need space after || src/hotspot/share/oops/fieldInfo.cpp line 45: > 43: } > 44: > 45: void FieldInfo::print_from_growable_array(GrowableArray* array, outputStream* os, ConstantPool* cp) { For consistency, can you make the outputStream parameter first? src/hotspot/share/oops/instanceKlass.hpp line 32: > 30: #include "oops/constMethod.hpp" > 31: #include "oops/constantPool.hpp" > 32: #include "oops/fieldInfo.inline.hpp" This shouldn't have an inline.hpp inclusion. src/hotspot/share/runtime/vmStructs.cpp line 2304: > 2302: declare_constant(FieldInfo::FieldFlags::_ff_generic) \ > 2303: declare_constant(FieldInfo::FieldFlags::_ff_stable) \ > 2304: declare_constant(FieldInfo::FieldFlags::_ff_contended) \ If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12855 From coleenp at openjdk.org Mon Mar 13 16:51:25 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Mar 2023 16:51:25 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 20:49:04 GMT, Frederic Parain wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 1491: >> >>> 1489: _temp_field_info = new GrowableArray(total_fields); >>> 1490: >>> 1491: ResourceMark rm(THREAD); >> >> Is the ResourceMark ok here or should it go before allocating _temp_field_info ? > > _temp_field_info must survive after ClassFileParser::parse_fields() has returned, so definitively after the allocation of _temp_field_info. That being said, I don't see any reason to have a ResourceMark here, probably a remain of some debugging/tracing code. I'll remove it. ok, good. The ResourceMark might be a problem with the GrowableArray if it grows. >> src/hotspot/share/classfile/classFileParser.cpp line 1608: >> >>> 1606: fflags.update_injected(true); >>> 1607: AccessFlags aflags; >>> 1608: FieldInfo fi(aflags, (u2)(injected[n].name_index), (u2)(injected[n].signature_index), 0, fflags); >> >> I don't know why there's a cast here until I read more. If the FieldInfo name_index and signature_index fields are only u2 sized, could you pass this as an int and then in the constructor assert that the value doesn't overflow u2 instead? > > The type of name_index and signature_index is const vmSymbolID, because they names and signatures of injected fields do not come from a constant pool, but from the vmSymbol array. ok the cast is fine here. >> src/hotspot/share/oops/fieldStreams.hpp line 104: >> >>> 102: AccessFlags flags; >>> 103: flags.set_flags(field()->access_flags()); >>> 104: return flags; >> >> Did this used to do this for a reason? > > Using the setter rather than the constructor filters out the VM defined flags and keeps only the flags from the class file. I see, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From coleenp at openjdk.org Mon Mar 13 16:51:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Mar 2023 16:51:29 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 15:53:03 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> SA additional caching from Chris Plummer > > src/hotspot/share/classfile/classFileParser.cpp line 1634: > >> 1632: for(int i = 0; i < _temp_field_info->length(); i++) { >> 1633: name = _temp_field_info->adr_at(i)->name(_cp); >> 1634: sig = _temp_field_info->adr_at(i)->signature(_cp); > > This checking for duplicates looks like a good candidate for a separate function because parse_fields is so long. I'm adding this comment to remember to file an RFE to look into making this function shorter and factor out this code. Filed a cleanup RFE https://bugs.openjdk.org/browse/JDK-8304069 ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Mon Mar 13 17:32:35 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 17:32:35 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: Message-ID: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com> On Mon, 13 Mar 2023 16:41:05 GMT, Coleen Phillimore wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> SA additional caching from Chris Plummer > > src/hotspot/share/runtime/vmStructs.cpp line 2304: > >> 2302: declare_constant(FieldInfo::FieldFlags::_ff_generic) \ >> 2303: declare_constant(FieldInfo::FieldFlags::_ff_stable) \ >> 2304: declare_constant(FieldInfo::FieldFlags::_ff_contended) \ > > If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA. The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flags that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From cjplummer at openjdk.org Mon Mar 13 18:02:28 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 13 Mar 2023 18:02:28 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com> References: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com> Message-ID: On Mon, 13 Mar 2023 17:29:28 GMT, Frederic Parain wrote: >> src/hotspot/share/runtime/vmStructs.cpp line 2304: >> >>> 2302: declare_constant(FieldInfo::FieldFlags::_ff_generic) \ >>> 2303: declare_constant(FieldInfo::FieldFlags::_ff_stable) \ >>> 2304: declare_constant(FieldInfo::FieldFlags::_ff_contended) \ >> >> If there are flags that SA doesn't use, like contended, I don't think they should be included in the information that we pass to SA. > > The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flag that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit. Leaving it in allows the field to be displayed if an SA user ever dumps a FieldFlags object. Generally speaking it is good to keep these structs complete, or at least complete with any info that might be useful when debugging with SA. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Mon Mar 13 18:51:17 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 18:51:17 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Fixes includes and style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12855/files - new: https://git.openjdk.org/jdk/pull/12855/files/322b626d..12b4f1b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=02-03 Stats: 9 lines in 5 files changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Mon Mar 13 18:51:20 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 13 Mar 2023 18:51:20 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v3] In-Reply-To: References: <-zydTVMcZURxcBOz8Rj5Gi0DUtqkANHuYnSUStzY0dY=.2c84dc16-4d7a-44fc-a27c-0ffb9f56bec8@github.com> Message-ID: On Mon, 13 Mar 2023 17:59:03 GMT, Chris Plummer wrote: >> The contended flag is required to be able to decode the compressed stream, because it signals the presence of an optional part of a field description. The only flag that was not required for the decoding of the stream and was not used by the SA was Stable, and I'll remove it in the next commit. > > Leaving it in allows the field to be displayed if an SA user ever dumps a FieldFlags object. Generally speaking it is good to keep these structs complete, or at least complete with any info that might be useful when debugging with SA. The "stable" flag and the related methods have been preserved in the last commit. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From coleenp at openjdk.org Mon Mar 13 20:42:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 13 Mar 2023 20:42:29 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: <3YhDOFYnbJ4QsrXUQbUQfFbXHb75eK1Mowuv9yYaXqE=.62fc2fd0-5384-440d-919a-1c59e9b2f3fb@github.com> On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes includes and style All my comments are addressed. Thank you! This is significant work. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12855 From kvn at openjdk.org Mon Mar 13 21:18:58 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 13 Mar 2023 21:18:58 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v3] In-Reply-To: References: Message-ID: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - merged master and resolved condlicts - Address comments - 8303415: Add VM_Version::is_intrinsic_supported(id) ------------- Changes: https://git.openjdk.org/jdk/pull/12858/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=02 Stats: 345 lines in 25 files changed: 211 ins; 93 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/12858.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12858/head:pull/12858 PR: https://git.openjdk.org/jdk/pull/12858 From dnsimon at openjdk.org Mon Mar 13 21:57:43 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 13 Mar 2023 21:57:43 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes includes and style src/hotspot/share/jvmci/jvmciEnv.cpp line 1439: > 1437: JNIAccessMark jni(this, THREAD); > 1438: jobject result = jni()->NewObject(JNIJVMCI::FieldInfo::clazz(), > 1439: JNIJVMCI::VMFlag::constructor(), `JNIJVMCI::VMFlag::constructor()` is the wrong constructor. src/hotspot/share/jvmci/jvmciEnv.hpp line 149: > 147: }; > 148: > 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong); What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 416: > 414: declare_constant(FieldInfo::FieldFlags::_ff_injected) \ > 415: declare_constant(FieldInfo::FieldFlags::_ff_stable) \ > 416: declare_constant(FieldInfo::FieldFlags::_ff_generic) \ I don't think `_ff_generic` is used in the JVMCI Java code so this entry can be deleted. Please double check the other entries. src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 814: > 812: HotSpotResolvedObjectTypeImpl resolvedHolder; > 813: try { > 814: resolvedHolder = compilerToVM().resolveFieldInPool(this, index, (HotSpotResolvedJavaMethodImpl) method, (byte) opcode, info); Please update the javadoc for `CompilerToVM.resolveFieldInPool` to reflect the expanded definition of `info`. src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java line 88: > 86: > 87: /** > 88: * Lazily initialized cache for FieldInfo nit: missing `.` at end of sentence src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48: > 46: * Returns VM internal flags associated with this field > 47: */ > 48: int getInternalModifiers(); We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method. test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java line 97: > 95: > 96: @Test > 97: public void getInternalModifiersTest() { No need for this test since the `getInternalModifiers` method should be removed. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From cjplummer at openjdk.org Tue Mar 14 01:28:57 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 14 Mar 2023 01:28:57 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes includes and style Changes requested by cjplummer (Reviewer). src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 75: > 73: int initialValueIndex; > 74: int genericSignatureIndex; > 75: int contendedGroup; It seems that these should all be shorts. All the getter methods are casting them to short. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 99: > 97: if (fieldIsInitialized(fieldInfoValues.fieldFlags)) fieldInfoValues.initialValueIndex = crs.readInt(); // read initial value index > 98: if (fieldIsGeneric(fieldInfoValues.fieldFlags)) fieldInfoValues.genericSignatureIndex = crs.readInt(); // read generic signature index > 99: if (fieldIsContended(fieldInfoValues.fieldFlags)) fieldInfoValues.contendedGroup = crs.readInt(); // read contended group Column with is too wide. These lines would be easier to read if you made each one multiple lines with curly braces. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 107: > 105: int javafieldsCount = crs.readInt(); // read num_java_fields > 106: int VMFieldsCount = crs.readInt(); // read num_injected_fields; > 107: int numFields = javafieldsCount + VMFieldsCount; VMFieldsCount -> vmFieldsCount, or maybe just use num_java_fields and num_injected_fields src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 285: > 283: public short getFieldNameIndex(int index) { > 284: if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;"); > 285: return (short)getField(index).getNameIndex(); Cast to short not needed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 303: > 301: public short getFieldSignatureIndex(int index) { > 302: if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;"); > 303: return (short)getField(index).getGenericSignatureIndex(); Cast to short is not needed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 321: > 319: public short getFieldInitialValueIndex(int index) { > 320: if (index >= getJavaFieldsCount()) throw new IndexOutOfBoundsException("not a Java field;"); > 321: return (short)getField(index).getInitialValueIndex(); cast to short is not needed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 325: > 323: > 324: public int getFieldOffset(int index) { > 325: return (int)getField(index).getOffset(); Cast to int is not needed ------------- PR: https://git.openjdk.org/jdk/pull/12855 From cjplummer at openjdk.org Tue Mar 14 02:03:32 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 14 Mar 2023 02:03:32 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fixes includes and style src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 108: > 106: CLASS_STATE_INITIALIZATION_ERROR = db.lookupIntConstant("InstanceKlass::initialization_error").intValue(); > 107: // We need a new fieldsCache each time we attach. > 108: fieldsCache = new HashMap(); This should probably be a WeakHashMap. I tried it and it seems to work (or at least didn't cause any problems). However, when doing a heap dump I didn't notice the table being any smaller on exit when it was made weak, even though there were numerous GC's while dumping the heap. The is the Address of the hotspot InstanceKlass instance, and this Address is referenced by the SA InstanceKlass mirror. So theoretically when the reference to the mirror goes way, then the cache entry can be cleared. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From dholmes at openjdk.org Tue Mar 14 03:06:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Mar 2023 03:06:54 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> Message-ID: On Mon, 13 Mar 2023 13:52:04 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/placeholders.cpp line 137: >> >>> 135: assert(action != PlaceholderTable::LOAD_INSTANCE || !EnableWaitForParallelLoad || seen == nullptr, >>> 136: "Only one LOAD_INSTANCE allowed at a time"); >>> 137: >> >> Getting rid of the full assertion seems to go beyond obsoleting EnableWaitForParallelLoad. > > The assertion reduces to something somewhat useless. Without EnableWaitForParallel load, you can have more then one thread with a LOAD_INSTANCE placeholder. These threads will wait when the go call into ClassLoader.loadClass() now. > There is nothing to assert here anymore. Okay. I confess I don't fully grok this part though. >> src/hotspot/share/classfile/systemDictionary.cpp line 564: >> >>> 562: >>> 563: // For bootstrap and non-parallelCapable class loaders, check and wait for >>> 564: // another thread to complete loading this class. >> >> A replacement comment describing the method would be nice. > > Ok, how about > // Check for other threads loading this class either to throw CCE or wait in the case of the boot loader. Ok >> src/hotspot/share/classfile/systemDictionary.cpp line 604: >> >>> 602: } else { >>> 603: return nullptr; >>> 604: } >> >> Again unclear how this all disappears just because the flag is obsoleted. > > Only the bootclass loader waits on the SystemDictionary_lock for multiple threads now. Not the non-parallel capable class loaders. Got it. `must_wait_for_class_loading` implies boot-loader, so the original `return nullptr` is now handled outside the `if (must_wait_for_class_loading)`. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From dholmes at openjdk.org Tue Mar 14 03:06:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Mar 2023 03:06:57 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> Message-ID: On Fri, 10 Mar 2023 13:41:15 GMT, Coleen Phillimore wrote: > This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 > and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 > > Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 > > Tested with tier1-7. src/hotspot/share/classfile/systemDictionary.cpp line 655: > 653: // is called. A LOAD_INSTANCE placeholder isn't used for mutual exclusion. > 654: // case 3. traditional classloaders that rely on the classloader object lock > 655: // There should be no need for need for LOAD_INSTANCE for mutual exclusion, The comment on L646 needs updating: only three cases now. src/hotspot/share/runtime/objectMonitor.cpp line 1375: > 1373: // reenter() enters a lock and sets recursion count > 1374: // complete_exit/reenter operate as a wait without waiting > 1375: bool ObjectMonitor::reenter(intx recursions, JavaThread* current) { AFAICS `complete_exit` is also unused now ------------- PR: https://git.openjdk.org/jdk/pull/12974 From lmesnik at openjdk.org Tue Mar 14 03:25:57 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 14 Mar 2023 03:25:57 GMT Subject: RFR: 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" Message-ID: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> The same bug as https://bugs.openjdk.org/browse/JDK-8295099 vmTestbase/nsk/stress/strace/strace013.java failed with "TestFailure: wrong lengths of stack traces: strace013Thread0: NNN strace013Thread83: MMM" The test starts failing after changing implementation of Object.wait() method in loom. This method might call Object.wait() and increase stack length of dump. ------------- Commit messages: - 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" Changes: https://git.openjdk.org/jdk/pull/13008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300317 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13008/head:pull/13008 PR: https://git.openjdk.org/jdk/pull/13008 From dholmes at openjdk.org Tue Mar 14 04:37:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Mar 2023 04:37:45 GMT Subject: RFR: 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" In-Reply-To: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> References: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> Message-ID: On Tue, 14 Mar 2023 00:45:03 GMT, Leonid Mesnik wrote: > The same bug as https://bugs.openjdk.org/browse/JDK-8295099 vmTestbase/nsk/stress/strace/strace013.java failed with "TestFailure: wrong lengths of stack traces: strace013Thread0: NNN strace013Thread83: MMM" > > The test starts failing after changing implementation of Object.wait() method in loom. This method might call Object.wait() and increase stack length of dump. Given that StraceBase doesn't even check specific methods any more I don't see that the stacktrace length check in these tests serves any purpose. As long as only the expected classes appear then the actual methods (and number thereof) seems irrelevant. But in terms of fixing this in the same way as the other test this seems fine. Note that the main test comments on this test (and likely the others) is no longer accurate. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/13008 From kvn at openjdk.org Tue Mar 14 05:22:57 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 14 Mar 2023 05:22:57 GMT Subject: RFR: 8303415: Add VM_Version::is_intrinsic_supported(id) [v4] In-Reply-To: References: Message-ID: <9jI8j1lHAB1JuFIPlDgXjyp-WzkoiTrx4YJR17-WdIY=.456c5092-7383-4738-940f-f91438cd7e3f@github.com> > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Additional Interpreter changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12858/files - new: https://git.openjdk.org/jdk/pull/12858/files/6be43779..98304c83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12858&range=02-03 Stats: 1025 lines in 9 files changed: 288 ins; 384 del; 353 mod Patch: https://git.openjdk.org/jdk/pull/12858.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12858/head:pull/12858 PR: https://git.openjdk.org/jdk/pull/12858 From mbaesken at openjdk.org Tue Mar 14 08:12:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Mar 2023 08:12:20 GMT Subject: Integrated: JDK-8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 11:37:27 GMT, Matthias Baesken wrote: > The test fails with > > [dwarf] ##### Find filename and line number for offset 0x000096a8 in library /lib64/glibc-hwcaps/power9/libpthread-2.28.so ##### > [dwarf] Failed to load DWARF file for library /lib64/glibc-hwcaps/power9/libpthread-2.28.so or find DWARF sections directly inside it. > > and in stderr > > java.lang.RuntimeException: Must find library in "C [libpthread-2.28.so+0x96a8] start_thread+0xf8": expected true, was false > > Looks like the '-' in the lib-name libpthread-2.28.so is currently not allowed in the pattern of the test. This is similar to [JDK-8293201](https://bugs.openjdk.org/browse/JDK-8293201) . This pull request has now been integrated. Changeset: b6d70f2c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b6d70f2c49da6f99e3a0a84b1df6e3d48c7e2e58 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8303973: Library detection in runtime/ErrorHandling/TestDwarf.java fails on ppc64le RHEL8.5 for libpthread-2.28.so Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/12998 From duke at openjdk.org Tue Mar 14 10:27:09 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 14 Mar 2023 10:27:09 GMT Subject: RFR: 8300840: Update test runtime/Thread/StopAtExit.java to include Null Pointer Exception as one of the allowed exceptions Message-ID: In the test, NPE is caught with no action. ### Test mach5 tier1-5 ------------- Commit messages: - 8300840: Update test runtime/Thread/StopAtExit.java to include Null Pointer Exception as one of the allowed exceptions Changes: https://git.openjdk.org/jdk/pull/13013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300840 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13013.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13013/head:pull/13013 PR: https://git.openjdk.org/jdk/pull/13013 From kevinw at openjdk.org Tue Mar 14 11:13:51 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 14 Mar 2023 11:13:51 GMT Subject: RFR: 8301065: Handle control characters in java_lang_String::print In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:51:37 GMT, Kevin Walls wrote: > Change to avoid printing raw control characters in java_lang_String::print. > Usually called in debug printing and error reporting. One usage from debug logging for modules. > > Format as \x followed by two hex digits, e.g. \x0A > > Small change, in a routine with few callers. Could make two calls to value->byte_at(), which I left in as it reads more clearly, and this is not called at time critical situations. > > The error reporting and debug.cpp usages I can test manually, with some trial and error, trying to catch the register info containing relevant info. This same String printing routine is used for showing register contents or stack slot mappings, and for a String, or a class containing a String. > > Before the change: (newlines and null embedded in String) > > R11=0x000000011f74e568 is an oop: java.lang.String > {0x000000011f74e568} - klass: 'java/lang/String' > - string: "this is my string > ^@and also: this is more of my string > " > - ---- fields (total size 3 words): > - private 'hash' 'I' @12 0 (0x00000000) > > > > With the change: > > {0x000000011faf5bf0} - klass: 'Test' > - ---- fields (total size 3 words): > - private 'lastChar' 'C' @12 10 (0x000a) > - private 'myString' 'Ljava/lang/String;' @16 "this is my string\x0A\x00and also: this is more of my string\x0A"{0x000000011faf5ca8} (0x23f5eb95) > R15=0x00007f928002a260 is a thread (I will get back to this...) ------------- PR: https://git.openjdk.org/jdk/pull/12190 From jsjolen at openjdk.org Tue Mar 14 12:12:50 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 14 Mar 2023 12:12:50 GMT Subject: RFR: 8270865: Print process ID with -Xlog:os Message-ID: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> Adds logging of the process ID fairly early in the process (right after `HOTSPOT_VM_INIT_END();`) as a quality of life improvement. Citing the ticket: > It's useful to add the PID into a log file. For example, we can use it to find the corresponding hs_err_.log ------------- Commit messages: - Log the PID of the initialized VM Changes: https://git.openjdk.org/jdk/pull/13015/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8270865 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13015.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13015/head:pull/13015 PR: https://git.openjdk.org/jdk/pull/13015 From kvn at openjdk.org Tue Mar 14 12:23:55 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 14 Mar 2023 12:23:55 GMT Subject: Integrated: 8303415: Add VM_Version::is_intrinsic_supported(id) In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 16:16:08 GMT, Vladimir Kozlov wrote: > Currently we check VM flags, directives and JIT compiler support when we generate intrinsics. > We have *product* VM flags for most intrinsics and set them in VM based on HW support. > But not all intrinsics have such flags and it is not scalable to add new *product* flag for each new intrinsic. > Also we have `-XX:DisableIntrinsic=` and `-XX:ControlIntrinsic=` flags to control intrinsics from command line. We don't need specific flags for that. > > I propose to add new `VM_Version::is_intrinsic_supported(id)` method to check platform support for intrinsic without adding new flag. I used it for `_floatToFloat16` intrinsic for my work on [JDK-8302976](https://bugs.openjdk.org/browse/JDK-8302976). > > Additional fixes: > Fixed Interpreter to skip intrinsics if they are disabled with flag. > Moved Interpreter's `InlineIntrinsics` flag check into one place in shared code. > Added separate interpreter id for `_dsqrt_strict` so it could be disabled separately from regular `_dsqrt`. > Added missing `native` mark to `_currentThread`. > Removed unused `AbstractInterpreter::in_native_entry()`. > Cleanup C2 intrinsic checks code. > > Tested tier1-4,xcomp,stress. Also ran tier1-3,xcomp with `-XX:-InlineIntrinsics`. This pull request has now been integrated. Changeset: ec1eb00e Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/ec1eb00ed3290f44bdb175e0ca05522fd860efa1 Stats: 1242 lines in 25 files changed: 401 ins; 379 del; 462 mod 8303415: Add VM_Version::is_intrinsic_supported(id) Reviewed-by: thartmann, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12858 From fparain at openjdk.org Tue Mar 14 13:15:54 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 14 Mar 2023 13:15:54 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: On Mon, 13 Mar 2023 21:53:37 GMT, Doug Simon wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes includes and style > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48: > >> 46: * Returns VM internal flags associated with this field >> 47: */ >> 48: int getInternalModifiers(); > > We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method. Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you? ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Tue Mar 14 13:19:37 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 14 Mar 2023 13:19:37 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: On Mon, 13 Mar 2023 21:44:59 GMT, Doug Simon wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes includes and style > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 416: > >> 414: declare_constant(FieldInfo::FieldFlags::_ff_injected) \ >> 415: declare_constant(FieldInfo::FieldFlags::_ff_stable) \ >> 416: declare_constant(FieldInfo::FieldFlags::_ff_generic) \ > > I don't think `_ff_generic` is used in the JVMCI Java code so this entry can be deleted. Please double check the other entries. _ff_generic removed. _ff_stable is used in `HotSpotResolvedJavaFieldImpl.isStable()`. _ff_injected is used in `HotSpotResolvedJavaFieldImpl.isInternal()` ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Tue Mar 14 13:40:55 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 14 Mar 2023 13:40:55 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: On Mon, 13 Mar 2023 21:35:17 GMT, Doug Simon wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes includes and style > > src/hotspot/share/jvmci/jvmciEnv.hpp line 149: > >> 147: }; >> 148: >> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong); > > What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public. Without this declaration, builds fail on Windows with this error: `error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage` ------------- PR: https://git.openjdk.org/jdk/pull/12855 From coleenp at openjdk.org Tue Mar 14 14:04:40 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Mar 2023 14:04:40 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> Message-ID: <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> > This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 > and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 > > Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 > > Tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12974/files - new: https://git.openjdk.org/jdk/pull/12974/files/80d6aff0..14f56319 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12974&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12974&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12974.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12974/head:pull/12974 PR: https://git.openjdk.org/jdk/pull/12974 From coleenp at openjdk.org Tue Mar 14 14:04:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Mar 2023 14:04:42 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> Message-ID: On Tue, 14 Mar 2023 03:04:03 GMT, David Holmes wrote: >> The assertion reduces to something somewhat useless. Without EnableWaitForParallel load, you can have more then one thread with a LOAD_INSTANCE placeholder. These threads will wait when the go call into ClassLoader.loadClass() now. >> There is nothing to assert here anymore. > > Okay. I confess I don't fully grok this part though. The bootloader uses LOAD_INSTANCE to wait for other threads (JVM implementation of parallel capable class loading), but this function doesn't pass the class_loader so that would be the only useful modification to this assert. But it seems too specific to actually catch any bugs. Before this change with EnableWaitForParallelLoad, the non-parallel-capable class loader would wait on the LOAD_INSTANCE placeholder with double_lock_wait so there would never be more than one. Now, both threads take out the placeholder, and are expected to wait in the ClassLoader.loadClass function. >> Only the bootclass loader waits on the SystemDictionary_lock for multiple threads now. Not the non-parallel capable class loaders. > > Got it. `must_wait_for_class_loading` implies boot-loader, so the original `return nullptr` is now handled outside the `if (must_wait_for_class_loading)`. Yes. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From coleenp at openjdk.org Tue Mar 14 14:04:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Mar 2023 14:04:42 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> Message-ID: <7S_Rtaw2fqbHCjCXyECG3ayk-rXg9p9u1w8EMLBv9T4=.d7b6aab5-2dd9-4cb3-8844-a7bef2166354@github.com> On Tue, 14 Mar 2023 13:54:20 GMT, Coleen Phillimore wrote: >> Okay. I confess I don't fully grok this part though. > > The bootloader uses LOAD_INSTANCE to wait for other threads (JVM implementation of parallel capable class loading), but this function doesn't pass the class_loader so that would be the only useful modification to this assert. But it seems too specific to actually catch any bugs. > Before this change with EnableWaitForParallelLoad, the non-parallel-capable class loader would wait on the LOAD_INSTANCE placeholder with double_lock_wait so there would never be more than one. Now, both threads take out the placeholder, and are expected to wait in the ClassLoader.loadClass function. If -Xcomp stopped calling load_signature_classes, we could remove the LOAD_INSTANCE placeholder for non-parallel capable class loaders. In the future. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From coleenp at openjdk.org Tue Mar 14 14:04:45 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 14 Mar 2023 14:04:45 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> Message-ID: <2oM8bwoeAV8lWflJ3cO65DBvk_M56yPctKqnBc9wL0o=.5bee8e55-8c62-413f-b428-5924a8172397@github.com> On Tue, 14 Mar 2023 02:48:19 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments. > > src/hotspot/share/classfile/systemDictionary.cpp line 655: > >> 653: // is called. A LOAD_INSTANCE placeholder isn't used for mutual exclusion. >> 654: // case 3. traditional classloaders that rely on the classloader object lock >> 655: // There should be no need for need for LOAD_INSTANCE for mutual exclusion, > > The comment on L646 needs updating: only three cases now. missed that. removed the line as it's unnecessary > src/hotspot/share/runtime/objectMonitor.cpp line 1375: > >> 1373: // reenter() enters a lock and sets recursion count >> 1374: // complete_exit/reenter operate as a wait without waiting >> 1375: bool ObjectMonitor::reenter(intx recursions, JavaThread* current) { > > AFAICS `complete_exit` is also unused now It is still used here: // Monitor cleanup on JavaThread::exit ------------- PR: https://git.openjdk.org/jdk/pull/12974 From dnsimon at openjdk.org Tue Mar 14 15:13:00 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 14 Mar 2023 15:13:00 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com> On Tue, 14 Mar 2023 13:12:31 GMT, Frederic Parain wrote: >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java line 48: >> >>> 46: * Returns VM internal flags associated with this field >>> 47: */ >>> 48: int getInternalModifiers(); >> >> We've never exposed the internal modifiers before in public JVMCI API and we should refrain from doing so until there's a good reason to do so. Please remove this method. > > Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you? Just use reflection to read the internal flags (like this test already does for the `index` field). I've attached [review.patch](https://github.com/openjdk/jdk/files/10970245/review.patch) with this change and a few other changes I think should be made for better naming (plus one test cleanup). ------------- PR: https://git.openjdk.org/jdk/pull/12855 From matsaave at openjdk.org Tue Mar 14 15:14:04 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 14 Mar 2023 15:14:04 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode [v2] In-Reply-To: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> References: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> Message-ID: On Wed, 1 Mar 2023 23:31:00 GMT, Calvin Cheung wrote: >> Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. >> Otherwise, JVM crashes with the following message in the hs err log: >> `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > make the _methods array writable during dump time for old classes with jsr bytecode This makes sense, rewriting the method should rewrite the JSR bytecodes and any matching RET bytecodes. LGTM! ------------- Marked as reviewed by matsaave (Author). PR: https://git.openjdk.org/jdk/pull/12752 From duke at openjdk.org Tue Mar 14 17:18:12 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 14 Mar 2023 17:18:12 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v2] In-Reply-To: References: Message-ID: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > > ### Tests > local: > vmTestbase/nsk/monitoring/stress/classload > vmTestbase/nsk/jvmti/AttachOnDemand > vmTestbase/nsk/jdi/ObjectReference/referringObjects > vmTestbase/nsk/sysdict > mach5: tier 1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8301684: Fix test code to not get finalizer deprecation warnings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12968/files - new: https://git.openjdk.org/jdk/pull/12968/files/0199c036..15c2ef56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12968&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12968&range=00-01 Stats: 128 lines in 2 files changed: 5 ins; 101 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/12968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12968/head:pull/12968 PR: https://git.openjdk.org/jdk/pull/12968 From ccheung at openjdk.org Tue Mar 14 17:19:36 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 14 Mar 2023 17:19:36 GMT Subject: RFR: 8302795: Shared archive failed on old version class with jsr bytecode [v2] In-Reply-To: <8jurYzTunx8_HRvhXAcQNgLPECDL5buIY6CaQGRsWNE=.9c77d680-a250-4257-a8fe-c0b56c7733f2@github.com> References: <-Gj61F_8DSPcmEXmkLpJWzntgpm5I-T8-fte1O3BEG8=.7aaeb730-ed24-4011-bb07-7858cc7379fe@github.com> <8jurYzTunx8_HRvhXAcQNgLPECDL5buIY6CaQGRsWNE=.9c77d680-a250-4257-a8fe-c0b56c7733f2@github.com> Message-ID: On Tue, 7 Mar 2023 04:45:47 GMT, Yumin Qi wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> make the _methods array writable during dump time for old classes with jsr bytecode > > LGTM. We know after 49.0 (java 5), jsr will not be generated, so this should not be a problem for dynamic dumping too. Thanks @yminqi and @matias9927 for the review. ------------- PR: https://git.openjdk.org/jdk/pull/12752 From ccheung at openjdk.org Tue Mar 14 17:19:39 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 14 Mar 2023 17:19:39 GMT Subject: Integrated: 8302795: Shared archive failed on old version class with jsr bytecode In-Reply-To: References: Message-ID: On Fri, 24 Feb 2023 23:28:14 GMT, Calvin Cheung wrote: > Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code. > Otherwise, JVM crashes with the following message in the hs err log: > `Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.` > > Passed tiers 1 - 4 testing. This pull request has now been integrated. Changeset: 830fd413 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/830fd413461709a494bcb81952e5c32088676ee3 Stats: 158 lines in 4 files changed: 157 ins; 0 del; 1 mod 8302795: Shared archive failed on old version class with jsr bytecode Reviewed-by: minqi, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/12752 From dnsimon at openjdk.org Tue Mar 14 19:49:48 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 14 Mar 2023 19:49:48 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: On Tue, 14 Mar 2023 13:37:23 GMT, Frederic Parain wrote: >> src/hotspot/share/jvmci/jvmciEnv.hpp line 149: >> >>> 147: }; >>> 148: >>> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env, jobject, jobject, jlong); >> >> What's the purpose of this declaration? I don't think you need it or the `friend` declaration below since `new_FieldInfo(FieldInfo* fieldinfo, JVMCI_TRAPS)` is public. > > Without this declaration, builds fail on Windows with this error: > `error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage` Strange - thats not needed for other `JVMCIEnv` methods called from `jvmciCompilerToVM.cpp`. There must be some way to avoid this. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Tue Mar 14 19:49:49 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 14 Mar 2023 19:49:49 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> Message-ID: <0SZEwskweBz1Ri6krqHq9rGWvmwiQ9fkgfRcUEKtTuo=.67dbf4d3-4432-4187-a39d-f16ef76cc2ce@github.com> On Tue, 14 Mar 2023 15:11:36 GMT, Doug Simon wrote: >> Without this declaration, builds fail on Windows with this error: >> `error C2375: 'c2v_getDeclaredFieldsInfo': redefinition; different linkage` > > Strange - thats not needed for other `JVMCIEnv` methods called from `jvmciCompilerToVM.cpp`. There must be some way to avoid this. The issue was caused by the `friend` declaration below (I cannot remember why I added in the first place), which seems to add an implicit declaration of the method that was conflicting with the original declaration of the method. Once the `friend` declaration is removed, builds on Windows don't need the `extern` declaration anymore. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From dcubed at openjdk.org Tue Mar 14 20:06:01 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 14 Mar 2023 20:06:01 GMT Subject: RFR: 8304172: ProblemList serviceability/sa/UniqueVtableTest.java Message-ID: Trivial fixes to ProblemList a couple of tests: [JDK-8304172](https://bugs.openjdk.org/browse/JDK-8304172) ProblemList serviceability/sa/UniqueVtableTest.java [JDK-8304175](https://bugs.openjdk.org/browse/JDK-8304175) ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms ------------- Commit messages: - 8304175: ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms - 8304172: ProblemList serviceability/sa/UniqueVtableTest.java Changes: https://git.openjdk.org/jdk/pull/13029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304172 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13029/head:pull/13029 PR: https://git.openjdk.org/jdk/pull/13029 From azvegint at openjdk.org Tue Mar 14 20:06:03 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 14 Mar 2023 20:06:03 GMT Subject: RFR: 8304172: ProblemList serviceability/sa/UniqueVtableTest.java In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 19:52:01 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > > [JDK-8304172](https://bugs.openjdk.org/browse/JDK-8304172) ProblemList serviceability/sa/UniqueVtableTest.java > [JDK-8304175](https://bugs.openjdk.org/browse/JDK-8304175) ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/13029 From dcubed at openjdk.org Tue Mar 14 20:09:13 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 14 Mar 2023 20:09:13 GMT Subject: RFR: 8304172: ProblemList serviceability/sa/UniqueVtableTest.java In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 20:00:30 GMT, Alexander Zvegintsev wrote: >> Trivial fixes to ProblemList a couple of tests: >> >> [JDK-8304172](https://bugs.openjdk.org/browse/JDK-8304172) ProblemList serviceability/sa/UniqueVtableTest.java >> [JDK-8304175](https://bugs.openjdk.org/browse/JDK-8304175) ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk/pull/13029 From dcubed at openjdk.org Tue Mar 14 20:13:18 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 14 Mar 2023 20:13:18 GMT Subject: Integrated: 8304172: ProblemList serviceability/sa/UniqueVtableTest.java In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 19:52:01 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > > [JDK-8304172](https://bugs.openjdk.org/browse/JDK-8304172) ProblemList serviceability/sa/UniqueVtableTest.java > [JDK-8304175](https://bugs.openjdk.org/browse/JDK-8304175) ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms This pull request has now been integrated. Changeset: 617c15f5 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/617c15f5a131fdf254fc4277f6dd78d64292db1c Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8304172: ProblemList serviceability/sa/UniqueVtableTest.java 8304175: ProblemList compiler/vectorapi/VectorLogicalOpIdentityTest.java on 2 platforms Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/13029 From fparain at openjdk.org Tue Mar 14 20:32:53 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 14 Mar 2023 20:32:53 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com> References: <5apLgAhjSwiK-sv6Xrl9yZctZTAe_GahWGyk8rUYgvk=.1af11917-7547-48ba-b958-01c6ef6f9f18@github.com> <23n-dTVRiGuVl7imPvKph7q43FuB1k7Hak6-mGNDKeM=.40ca325c-e53f-4950-bece-99b7e4f4d367@github.com> Message-ID: On Tue, 14 Mar 2023 15:10:04 GMT, Doug Simon wrote: >> Access to internal modifiers is needed in `HotSpotResolvedJavaFieldTest.testEquivalenceForInternalFields()`. I moved the declaration of the method to `HotSpotResolvedJavaField`. Does this change work for you? > > Just use reflection to read the internal flags (like this test already does for the `index` field). > > I've attached [review.patch](https://github.com/openjdk/jdk/files/10970245/review.patch) with this change and a few other changes I think should be made for better naming (plus one test cleanup). Thank you for the patch, it will be included in the next commit. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From dholmes at openjdk.org Tue Mar 14 21:37:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Mar 2023 21:37:32 GMT Subject: RFR: 8270865: Print process ID with -Xlog:os In-Reply-To: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> References: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> Message-ID: On Tue, 14 Mar 2023 12:03:41 GMT, Johan Sj?len wrote: > Adds logging of the process ID fairly early in the process (right after `HOTSPOT_VM_INIT_END();`) as a quality of life improvement. > > Citing the ticket: > >> It's useful to add the PID into a log file. For example, we can use it to find the corresponding hs_err_.log Seems fine. I could quibble about how to word this but it doesn't really matter. :) Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/13015 From lmesnik at openjdk.org Tue Mar 14 22:07:51 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 14 Mar 2023 22:07:51 GMT Subject: RFR: 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" In-Reply-To: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> References: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> Message-ID: On Tue, 14 Mar 2023 00:45:03 GMT, Leonid Mesnik wrote: > The same bug as https://bugs.openjdk.org/browse/JDK-8295099 vmTestbase/nsk/stress/strace/strace013.java failed with "TestFailure: wrong lengths of stack traces: strace013Thread0: NNN strace013Thread83: MMM" > > The test starts failing after changing implementation of Object.wait() method in loom. This method might call Object.wait() and increase stack length of dump. Thanks David. Test call 100 recursive calls and verifies that getAllStackTraces() length differ from getStackTrace() length less by 3. The implementation method which test doesn't control. So the reasons for this check remain the same. ------------- PR: https://git.openjdk.org/jdk/pull/13008 From ccheung at openjdk.org Tue Mar 14 23:48:44 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 14 Mar 2023 23:48:44 GMT Subject: RFR: 8270865: Print process ID with -Xlog:os In-Reply-To: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> References: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> Message-ID: On Tue, 14 Mar 2023 12:03:41 GMT, Johan Sj?len wrote: > Adds logging of the process ID fairly early in the process (right after `HOTSPOT_VM_INIT_END();`) as a quality of life improvement. > > Citing the ticket: > >> It's useful to add the PID into a log file. For example, we can use it to find the corresponding hs_err_.log Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/13015 From dholmes at openjdk.org Wed Mar 15 02:02:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 02:02:36 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> Message-ID: On Tue, 14 Mar 2023 14:04:40 GMT, Coleen Phillimore wrote: >> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 >> and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 >> >> Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Nothing further from me. Looks good. Thanks! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12974 From dholmes at openjdk.org Wed Mar 15 02:02:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 02:02:37 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <7S_Rtaw2fqbHCjCXyECG3ayk-rXg9p9u1w8EMLBv9T4=.d7b6aab5-2dd9-4cb3-8844-a7bef2166354@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2xyPZ2zjRAJXNXC4necXVqEzO0k4rCBVJ2J0z5ytdf8=.d222a8af-6a87-4790-8a4a-e52205d88bfb@github.com> <7S_Rtaw2fqbHCjCXyECG3ayk-rXg9p9u1w8EMLBv9T4=.d7b6aab5-2dd9-4cb3-8844-a7bef2166354@github.com> Message-ID: <4pE3hKQbiz-HryXINI7yuXUbKc45Cc5wDqK7GRIo0Mo=.163b3af5-5835-42c3-965f-9ba4c2add53c@github.com> On Tue, 14 Mar 2023 13:56:36 GMT, Coleen Phillimore wrote: >> The bootloader uses LOAD_INSTANCE to wait for other threads (JVM implementation of parallel capable class loading), but this function doesn't pass the class_loader so that would be the only useful modification to this assert. But it seems too specific to actually catch any bugs. >> Before this change with EnableWaitForParallelLoad, the non-parallel-capable class loader would wait on the LOAD_INSTANCE placeholder with double_lock_wait so there would never be more than one. Now, both threads take out the placeholder, and are expected to wait in the ClassLoader.loadClass function. > > If -Xcomp stopped calling load_signature_classes, we could remove the LOAD_INSTANCE placeholder for non-parallel capable class loaders. In the future. Okay. Thanks for the additional info. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From dholmes at openjdk.org Wed Mar 15 02:02:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 02:02:39 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <2oM8bwoeAV8lWflJ3cO65DBvk_M56yPctKqnBc9wL0o=.5bee8e55-8c62-413f-b428-5924a8172397@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <2oM8bwoeAV8lWflJ3cO65DBvk_M56yPctKqnBc9wL0o=.5bee8e55-8c62-413f-b428-5924a8172397@github.com> Message-ID: On Tue, 14 Mar 2023 13:58:39 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1375: >> >>> 1373: // reenter() enters a lock and sets recursion count >>> 1374: // complete_exit/reenter operate as a wait without waiting >>> 1375: bool ObjectMonitor::reenter(intx recursions, JavaThread* current) { >> >> AFAICS `complete_exit` is also unused now > > It is still used here: // Monitor cleanup on JavaThread::exit Doh! Thanks missed ReleaseJavaMonitorsClosure :( ------------- PR: https://git.openjdk.org/jdk/pull/12974 From dholmes at openjdk.org Wed Mar 15 05:19:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 05:19:26 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v2] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 17:18:12 GMT, Afshin Zafari wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> >> ### Tests >> local: >> vmTestbase/nsk/monitoring/stress/classload >> vmTestbase/nsk/jvmti/AttachOnDemand >> vmTestbase/nsk/jdi/ObjectReference/referringObjects >> vmTestbase/nsk/sysdict >> mach5: tier 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301684: Fix test code to not get finalizer deprecation warnings This looks much simpler/cleaner - thanks! Just a few nits with comments. Nice try with replacing "finalize" by "reclaim" but it doesn't quite work grammatically in the comments. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 52: > 50: * After setting the class loader to null, if within a timeout no notification > 51: * of its reclaim is received, class is considered still loaded and > 52: * unloadClass() method returns false. All of the existing commentary in this test is somewhat lacking in terms of grammatical correctness, but we can at least make improvements to the new text. I suggest the following: * A class is eligible for unloading if its class loader has been reclaimed. * A Cleaner is used to inform the main test code when the class loader * becomes unreachable and is reclaimed. * If, after setting the class loader to null, no notification that it has become * reclaimed is received within the timeout interval, then the class is considered * to still be loaded and unloadClass() returns false. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 80: > 78: > 79: /** > 80: * Whole amount of time in milliseconds to wait for class loader reclaim. s/reclaim/to be reclaimed/ test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 85: > 83: > 84: /** > 85: * Piece of time in milliseconds to wait in a loop for class loader reclaim. Suggestion: * Sleep time in milliseconds for the loop waiting for the class loader to be reclaimed. * ``` test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 90: > 88: > 89: /** > 90: * Has class loader been is_reclaimed or not. s/is_reclaimed/reclaimed/ test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 141: > 139: classObjects.removeAllElements(); > 140: > 141: // When customClassLoader becomes unreachable, the lambda is called by JVM/GC. Suggestion: // Register a Cleaner to inform us when the class loader has been reclaimed. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 157: > 155: classObjects.removeAllElements(); > 156: > 157: // When customClassLoader becomes unreachable, the lambda is called by JVM/GC. Suggestion: // Register a Cleaner to inform us when the class loader has been reclaimed. test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 277: > 275: } > 276: > 277: // class loader has not been is_reclaimed s/is_reclaimed/reclaimed/ ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12968 From lmesnik at openjdk.org Wed Mar 15 05:50:17 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 05:50:17 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output Message-ID: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. ------------- Commit messages: - fix - 8303697 Changes: https://git.openjdk.org/jdk/pull/13034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303697 Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Wed Mar 15 05:50:18 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 05:50:18 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. The ByteArrayOutputStream is moved into try block just to close it as any other stream. Doesn't affect execution. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From thartmann at openjdk.org Wed Mar 15 06:21:18 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 15 Mar 2023 06:21:18 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 18:17:09 GMT, Matias Saavedra Silva wrote: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. This should be reviewed by hotspot/runtime. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From dholmes at openjdk.org Wed Mar 15 06:59:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 06:59:19 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Not clear on this one sorry. I would have thought the: if (lastcrlf == -1) { was supposed to handle lines without final \n. But I really can't follow this code. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 56: > 54: test("ARG1\nARG2\n"); > 55: test("\nARG1\nARG2\n"); > 56: test("\nARG1\nVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINEVERYVERYLONGLINE" + "" + Probably easier/clearer to use String.repeat to create as long a line as you want. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Wed Mar 15 07:03:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Mar 2023 07:03:19 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 18:17:09 GMT, Matias Saavedra Silva wrote: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. I can't attest to the correctness of this by visual inspection. Have you tested exercising this code with suitable null arrays? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From duke at openjdk.org Wed Mar 15 10:19:08 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 15 Mar 2023 10:19:08 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v3] In-Reply-To: References: Message-ID: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > > ### Tests > local: > vmTestbase/nsk/monitoring/stress/classload > vmTestbase/nsk/jvmti/AttachOnDemand > vmTestbase/nsk/jdi/ObjectReference/referringObjects > vmTestbase/nsk/sysdict > mach5: tier 1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8301684: Fix test code to not get finalizer deprecation warnings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12968/files - new: https://git.openjdk.org/jdk/pull/12968/files/15c2ef56..58d24335 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12968&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12968&range=01-02 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12968.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12968/head:pull/12968 PR: https://git.openjdk.org/jdk/pull/12968 From duke at openjdk.org Wed Mar 15 10:19:10 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 15 Mar 2023 10:19:10 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v2] In-Reply-To: References: Message-ID: <9B8BK2293neNHbYawydwVtRyCHJxZ2aWIB5ff-UAOPQ=.63a59047-fcfd-4a2d-a00a-308d9d175796@github.com> On Wed, 15 Mar 2023 05:16:42 GMT, David Holmes wrote: > This looks much simpler/cleaner - thanks! > > Just a few nits with comments. Nice try with replacing "finalize" by "reclaim" but it doesn't quite work grammatically in the comments. Thanks for your comments, and thank you also for being patient with my naive mistakes. ------------- PR: https://git.openjdk.org/jdk/pull/12968 From jsjolen at openjdk.org Wed Mar 15 10:50:31 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Mar 2023 10:50:31 GMT Subject: RFR: 8270865: Print process ID with -Xlog:os In-Reply-To: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> References: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> Message-ID: On Tue, 14 Mar 2023 12:03:41 GMT, Johan Sj?len wrote: > Adds logging of the process ID fairly early in the process (right after `HOTSPOT_VM_INIT_END();`) as a quality of life improvement. > > Citing the ticket: > >> It's useful to add the PID into a log file. For example, we can use it to find the corresponding hs_err_.log Thanks :). ------------- PR: https://git.openjdk.org/jdk/pull/13015 From jsjolen at openjdk.org Wed Mar 15 10:50:32 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 15 Mar 2023 10:50:32 GMT Subject: Integrated: 8270865: Print process ID with -Xlog:os In-Reply-To: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> References: <6hme3vF-aTz6NUYhffAqZStSHuQogYNU21m0JeuNCLg=.411dad19-b2db-4aa2-b75d-3c993e375072@github.com> Message-ID: On Tue, 14 Mar 2023 12:03:41 GMT, Johan Sj?len wrote: > Adds logging of the process ID fairly early in the process (right after `HOTSPOT_VM_INIT_END();`) as a quality of life improvement. > > Citing the ticket: > >> It's useful to add the PID into a log file. For example, we can use it to find the corresponding hs_err_.log This pull request has now been integrated. Changeset: e3777b0c Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/e3777b0c49abb9cc1925f4044392afadf3adef61 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8270865: Print process ID with -Xlog:os Reviewed-by: dholmes, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/13015 From fparain at openjdk.org Wed Mar 15 13:45:46 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 15 Mar 2023 13:45:46 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4] In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 01:25:01 GMT, Chris Plummer wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes includes and style > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Field.java line 75: > >> 73: int initialValueIndex; >> 74: int genericSignatureIndex; >> 75: int contendedGroup; > > It seems that these should all be shorts. All the getter methods are casting them to short. Indexes in the constant pool are unsigned shorts, but Java shorts are signed, using ints is the simplest way to store those indexes. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 108: > >> 106: CLASS_STATE_INITIALIZATION_ERROR = db.lookupIntConstant("InstanceKlass::initialization_error").intValue(); >> 107: // We need a new fieldsCache each time we attach. >> 108: fieldsCache = new HashMap(); > > This should probably be a WeakHashMap. I tried it and it seems to work (or at least didn't cause any problems). However, when doing a heap dump I didn't notice the table being any smaller on exit when it was made weak, even though there were numerous GC's while dumping the heap. > > The `` is the Address of the hotspot InstanceKlass instance, and this Address is referenced by the SA InstanceKlass mirror. So theoretically when the reference to the mirror goes way, then the cache entry can be cleared. I've changed the map to a WeakHashMap and didn't see any issue during testing. But I didn't measure footprint. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 325: > >> 323: >> 324: public int getFieldOffset(int index) { >> 325: return (int)getField(index).getOffset(); > > Cast to int is not needed Other APIs (like MetadaField) are using longs to pass offsets, doing a cast here is less disruptive than changing all the other APIs. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From lmesnik at openjdk.org Wed Mar 15 14:23:06 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 14:23:06 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/2f33a8c4..7e0305d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=00-01 Stats: 12 lines in 1 file changed: 2 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Wed Mar 15 14:26:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 14:26:25 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 14:23:06 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test test/lib/jdk/test/lib/process/StreamPumper.java line 145: > 143: } > 144: } > 145: final String line = lineBos.toString(); The code in 'lastcrlf == -1' as well as in 'lastcrlf < len - 1' writes remaining buf into lineBos. This lineBos is used to make line which is processed in line 127. However, if the stream is emptied then the chunk after last '\n' is written in in the lineBos but we never reach line 127 to call processLine for it. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From fparain at openjdk.org Wed Mar 15 15:41:17 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 15 Mar 2023 15:41:17 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v5] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: SA and JVMCI fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12855/files - new: https://git.openjdk.org/jdk/pull/12855/files/12b4f1b4..f81337f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=03-04 Stats: 130 lines in 13 files changed: 14 ins; 46 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From coleenp at openjdk.org Wed Mar 15 16:10:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 15 Mar 2023 16:10:20 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 10:19:08 GMT, Afshin Zafari wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> >> ### Tests >> local: >> vmTestbase/nsk/monitoring/stress/classload >> vmTestbase/nsk/jvmti/AttachOnDemand >> vmTestbase/nsk/jdi/ObjectReference/referringObjects >> vmTestbase/nsk/sysdict >> mach5: tier 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301684: Fix test code to not get finalizer deprecation warnings This looks great. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12968 From cjplummer at openjdk.org Wed Mar 15 16:41:16 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 15 Mar 2023 16:41:16 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v5] In-Reply-To: References: Message-ID: <_thEXXKYB00W5Mmg8hGRKMLqo6vog84sjtp2Mqf2wqk=.8f5a76a6-30c5-4a05-ae7a-753e1d70ddee@github.com> On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > SA and JVMCI fixes SA changes looks good. Thanks for taking care of this! ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12855 From mseledtsov at openjdk.org Wed Mar 15 16:42:10 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 15 Mar 2023 16:42:10 GMT Subject: RFR: 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" In-Reply-To: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> References: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> Message-ID: <2NXugMEPmNU0e6_AYacYZk14PVWvNzr62BXQ0WuaFE8=.9aa5f170-6ee4-4248-94a8-52daf56fb57f@github.com> On Tue, 14 Mar 2023 00:45:03 GMT, Leonid Mesnik wrote: > The same bug as https://bugs.openjdk.org/browse/JDK-8295099 vmTestbase/nsk/stress/strace/strace013.java failed with "TestFailure: wrong lengths of stack traces: strace013Thread0: NNN strace013Thread83: MMM" > > The test starts failing after changing implementation of Object.wait() method in loom. This method might call Object.wait() and increase stack length of dump. Marked as reviewed by mseledtsov (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/13008 From lmesnik at openjdk.org Wed Mar 15 17:18:54 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 17:18:54 GMT Subject: Integrated: 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" In-Reply-To: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> References: <3R7IaHROkTb88CFMMMlZXnrcVqRxv1dxXHEPhnQE4v0=.425b7122-2756-4869-8d04-99dcc81d8327@github.com> Message-ID: <37K_X5rt4Luo4XG6plQpnAeMjcqOvlEhfXcyA1elw_E=.aeaf7e08-559f-4541-95d3-b9d6677b997e@github.com> On Tue, 14 Mar 2023 00:45:03 GMT, Leonid Mesnik wrote: > The same bug as https://bugs.openjdk.org/browse/JDK-8295099 vmTestbase/nsk/stress/strace/strace013.java failed with "TestFailure: wrong lengths of stack traces: strace013Thread0: NNN strace013Thread83: MMM" > > The test starts failing after changing implementation of Object.wait() method in loom. This method might call Object.wait() and increase stack length of dump. This pull request has now been integrated. Changeset: 7ad48ea3 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/7ad48ea3ad3e90de64fbc73bf6d555a567b994f4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8300317: vmTestbase/nsk/stress/strace/strace* tests fail with "ERROR: wrong lengths of stack traces" Reviewed-by: dholmes, mseledtsov ------------- PR: https://git.openjdk.org/jdk/pull/13008 From cslucas at openjdk.org Wed Mar 15 17:20:47 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 15 Mar 2023 17:20:47 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v2] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <8d3LAUIIFVAJIXyrV2YafqAtAe6yiSPUS5THd2VynTk=.006e4cf8-90fe-43ea-8bb3-bbda4d3244f9@github.com> > Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently. > > The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure. Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge master - Add support for rematerializing scalar replaced objects participating in allocation merges ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01 Stats: 1803 lines in 18 files changed: 1653 ins; 9 del; 141 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From kvn at openjdk.org Wed Mar 15 17:22:10 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 15 Mar 2023 17:22:10 GMT Subject: RFR: 8304267: JDK-8303415 missed change in Zero Interpreter Message-ID: Added missing lines to Zero Interpreter. Tested with building debug JDK with Zero JVM. ------------- Commit messages: - 8304267: JDK-8303415 missed change in Zero Interpreter Changes: https://git.openjdk.org/jdk/pull/13046/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304267 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13046.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13046/head:pull/13046 PR: https://git.openjdk.org/jdk/pull/13046 From dcubed at openjdk.org Wed Mar 15 17:40:23 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 15 Mar 2023 17:40:23 GMT Subject: RFR: 8304267: JDK-8303415 missed change in Zero Interpreter In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 17:14:30 GMT, Vladimir Kozlov wrote: > Added missing lines to Zero Interpreter. > > Tested with building debug JDK with Zero JVM. Thumbs up. This is a trivial fix. Thanks for including the testing info. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/13046 From cslucas at openjdk.org Wed Mar 15 18:06:58 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 15 Mar 2023 18:06:58 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v3] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR to add support for the rematerialization of scalar-replaced objects that participate in allocation merges? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges that are used *only* as debug information in SafePointNode and its subclasses. Although there is a performance benefit in doing scalar replacement in this scenario only, the goal of this PR is mainly to add infrastructure to support the rematerialization of SR objects participating in merges. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP, Load+AddP, primarily) subsequently. > > The approach I used is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in allocation merges used only as debug information. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression that might be related. I also tested with several applications and didn't see any failure. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Fix some typos and do some small refactorings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/ea67a304..3b492d2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=01-02 Stats: 72 lines in 8 files changed: 1 ins; 7 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From matsaave at openjdk.org Wed Mar 15 18:10:21 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 15 Mar 2023 18:10:21 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 07:00:38 GMT, David Holmes wrote: > I can't attest to the correctness of this by visual inspection. Have you tested exercising this code with suitable null arrays? > > Thanks. With the way the `null_check` method currently works, a null check will not be emitted unless one is needed as defined by `needs_explicit_null_check(offset)`. This method returns true only if the offset is less than 0 or greater than the page size, which is not possible, or at least unlikely, for values like `klass_offset_in_bytes()` and `length_offset_in_bytes()`. These fields are located near the top of the structure so the offset should be much smaller than the page size. Using null arrays will not trigger the removed null checks and will fail by NullPointerException or ArrayIndexOutofBoundsException later. The removed calls were not doing anything. I verified this with some simple tests locally and also updated the description with the tiered tests used. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From kvn at openjdk.org Wed Mar 15 18:11:32 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 15 Mar 2023 18:11:32 GMT Subject: RFR: 8304267: JDK-8303415 missed change in Zero Interpreter In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 17:14:30 GMT, Vladimir Kozlov wrote: > Added missing lines to Zero Interpreter. > > Tested with building debug JDK with Zero JVM. Thank you, David. ------------- PR: https://git.openjdk.org/jdk/pull/13046 From kvn at openjdk.org Wed Mar 15 18:11:33 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 15 Mar 2023 18:11:33 GMT Subject: Integrated: 8304267: JDK-8303415 missed change in Zero Interpreter In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 17:14:30 GMT, Vladimir Kozlov wrote: > Added missing lines to Zero Interpreter. > > Tested with building debug JDK with Zero JVM. This pull request has now been integrated. Changeset: 116627df Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/116627dfb0ef3ac4d4e4d3a37a7f028759429583 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8304267: JDK-8303415 missed change in Zero Interpreter Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/13046 From jvernee at openjdk.org Wed Mar 15 21:37:08 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Mar 2023 21:37:08 GMT Subject: RFR: 8304288: Add foreign linker tag set descriptions Message-ID: <-Qcz2jgRcJ294O7v_kRCHaNyFWABy8j_PuF_ZCUTeog=.facf987b-70d3-43c1-a673-6c94b69a36a7@github.com> Add foreign linker tag set descriptions for `foreign+downcall`, `foreign+upcall`, which are printed in -Xlog:help message. Sample output: Described tag sets: logging: Logging for the log framework itself foreign+downcall: Generation of foreign linker downcall stubs foreign+upcall: Generation of foreign linker upcall stubs Testing: manual testing + build on Windows with MSVC, and on Linux (WSL) with GCC. ------------- Commit messages: - add foreign linker tag set descriptions Changes: https://git.openjdk.org/jdk/pull/13051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304288 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13051.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13051/head:pull/13051 PR: https://git.openjdk.org/jdk/pull/13051 From lmesnik at openjdk.org Wed Mar 15 22:49:57 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Mar 2023 22:49:57 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: comments added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/7e0305d1..aa12782b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Thu Mar 16 02:48:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 02:48:26 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 18:06:52 GMT, Matias Saavedra Silva wrote: > Using null arrays will not trigger the removed null checks and will fail by NullPointerException or ArrayIndexOutofBoundsException later. That is all I wanted to verify: that we have tests, which use "null" for the array, which will exercise these code blocks and which behave the same both with and without the `null_check` calls. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From dholmes at openjdk.org Thu Mar 16 03:09:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 03:09:19 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 18:17:09 GMT, Matias Saavedra Silva wrote: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. So basically this change is statically deciding that `needs_explicit_null_check` will always be false at these call-sites. I find it hard to determine where the actual null check does occur for something like `arraylength()`? Shouldn't the same change be made for all the other platforms that use the same code here? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From dholmes at openjdk.org Thu Mar 16 04:43:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 04:43:22 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: <7a55yrOkgaBFFSRs_4gRTos5baERHoFuaXu4J29ioWI=.b35f6aa7-0102-4ca0-83d7-e1abe66800fb@github.com> On Wed, 15 Mar 2023 22:49:57 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > comments added A few minor suggestions. The additional commentary is very helpful. Figuring out exactly how this code works is painful. Thanks. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 50: > 48: > 49: // The line which exceeds internal StreamPumper buffer (256 bytes) > 50: String VERY_LONG_LINE = "VERYLONGLINE".repeat(30); It might be a bit more obvious that this does exceed 256 by simply doing: String veryLongLine = "X".repeat(257); test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 54: > 52: System.out.print(args[0]); > 53: } else { > 54: test("ARG1"); Some boundary testing here would be: test("\n"); test("\nARG1"); test("\nARG1\n"); test("ARG1/n"); test("ARG1"); test/lib/jdk/test/lib/process/StreamPumper.java line 99: > 97: * Implements Thread.run(). Continuously read from {@code in} and write to > 98: * {@code out} until {@code in} has reached end of stream. > 99: * Additionally this method also split data read from buffer into the lines and process each line using linePumps. A few grammatical nits. I suggest: > Additionally this method also splits the data read from the buffer into lines, and processes each line using linePumps. test/lib/jdk/test/lib/process/StreamPumper.java line 138: > 136: } > 137: // The remaining after last '\n' (lastcrlf position) buffer data is written into lineBos. > 138: // The end of this line from next buffer is concatenated to this data in the next iteration. In trying to help my own understanding here I suggest: // If no crlf was found, or there was additional data after the last crlf was found, then write the leftover data // in lineBos. If there is more data to read it will be concatenated with the current data on the next iteration. // If there is no more data, or no more crlf found, all the remaining data will be processed after the loop, as the // final line. test/lib/jdk/test/lib/process/StreamPumper.java line 149: > 147: } > 148: // Process data remaining after last '\n' in the last buffer. > 149: // It is already written in the lineBos buffer but not processed because '\n' hasn't been met. Suggestion: // If there was no terminating crlf the remaining data has been written to lineBos, but this final line of data // now needs to be processed by the linePumper. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Thu Mar 16 04:43:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 04:43:26 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v2] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 14:23:43 GMT, Leonid Mesnik wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed test > > test/lib/jdk/test/lib/process/StreamPumper.java line 145: > >> 143: } >> 144: } >> 145: final String line = lineBos.toString(); > > The code in 'lastcrlf == -1' as well as in 'lastcrlf < len - 1' writes remaining buf into lineBos. This lineBos is used to make line which is processed in line 127. > However, if the stream is emptied then the chunk after last '\n' is written in in the lineBos but we never reach line 127 to call processLine for it. Thanks for the additional offline explanations about this code. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Thu Mar 16 06:08:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 06:08:23 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 10:19:08 GMT, Afshin Zafari wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> >> ### Tests >> local: >> vmTestbase/nsk/monitoring/stress/classload >> vmTestbase/nsk/jvmti/AttachOnDemand >> vmTestbase/nsk/jdi/ObjectReference/referringObjects >> vmTestbase/nsk/sysdict >> mach5: tier 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301684: Fix test code to not get finalizer deprecation warnings Looks good. Thanks for fixing this. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12968 From stuefe at openjdk.org Thu Mar 16 06:22:21 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 16 Mar 2023 06:22:21 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: On Wed, 15 Mar 2023 22:49:57 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > comments added That also affects OutputAnalyzer, right? Does this affect parsing or is this only printing? Anyway, patch looks good to me, modulo of what David wrote. If you fix his remarks, its good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/13034 From jsjolen at openjdk.org Thu Mar 16 08:40:10 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 16 Mar 2023 08:40:10 GMT Subject: RFR: 8304130: Add runtime/StackGuardPages/TestStackGuardPagesNative.java to ProblemList.txt Message-ID: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> This test intermittently fails and it's unlikely that further failures will give us any more information on how to solve the problem. ------------- Commit messages: - Problem list TestStackGuardPagesNative Changes: https://git.openjdk.org/jdk/pull/13016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304130 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13016.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13016/head:pull/13016 PR: https://git.openjdk.org/jdk/pull/13016 From dnsimon at openjdk.org Thu Mar 16 15:13:32 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 16 Mar 2023 15:13:32 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v5] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > SA and JVMCI fixes Marked as reviewed by dnsimon (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12855 From dcubed at openjdk.org Thu Mar 16 18:06:23 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Mar 2023 18:06:23 GMT Subject: RFR: 8304130: Add runtime/StackGuardPages/TestStackGuardPagesNative.java to ProblemList.txt In-Reply-To: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> References: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> Message-ID: <-RghkPa0VBwwoqbl1p8XMn0m_fWosX2_h1wJ5r4UpUM=.dc05f355-f1f7-4709-a777-4c94e3337481@github.com> On Tue, 14 Mar 2023 12:19:08 GMT, Johan Sj?len wrote: > This test intermittently fails and it's unlikely that further failures will give us any more information on how to solve the problem. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/13016 From matsaave at openjdk.org Thu Mar 16 20:02:56 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 16 Mar 2023 20:02:56 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: load_klass now emits null check and other platforms supported ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/76daacdc..391af540 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=00-01 Stats: 20 lines in 10 files changed: 0 ins; 14 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From matsaave at openjdk.org Thu Mar 16 20:54:27 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 16 Mar 2023 20:54:27 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > load_klass now emits null check and other platforms supported I have now added support for the other platforms. In addition, I noticed that in `load_klass_check_null` the check was never generated when by all means it should be. Instead of removing these checks to maintain the current behavior, I think it would be best to implement the intended functionality. Otherwise `load_klass_check_null` does nothing else but call `load_klass` with a potentially null klass. Given that this has passed under the radar until recently, there must be existing checks down the line that check for nulls. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From dholmes at openjdk.org Thu Mar 16 22:38:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Mar 2023 22:38:39 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v5] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > SA and JVMCI fixes Nice piece of work Fred - I won't pretend to follow every detail. A few nits on unnecessary alignment (which may match pre-existing style not evident in the diff). Thanks. src/hotspot/share/oops/fieldInfo.inline.hpp line 170: > 168: new_flags = old_flags & ~mask; > 169: witness = Atomic::cmpxchg(&flags, old_flags, new_flags); > 170: } while(witness != old_flags); Just to prove I did read this :) space needed after `while` src/hotspot/share/oops/fieldInfo.inline.hpp line 174: > 172: > 173: inline void FieldStatus::update_flag(FieldStatusBitPosition pos, bool z) { > 174: if (z) atomic_set_bits( _flags, flag_mask(pos)); Nit: extra space before `_flags` src/hotspot/share/oops/fieldInfo.inline.hpp line 175: > 173: inline void FieldStatus::update_flag(FieldStatusBitPosition pos, bool z) { > 174: if (z) atomic_set_bits( _flags, flag_mask(pos)); > 175: else atomic_clear_bits(_flags, flag_mask(pos)); Nit: no need for the extra spaces. If you really want these to align just place them on ne wlines. src/hotspot/share/oops/instanceKlass.inline.hpp line 50: > 48: > 49: inline Symbol* InstanceKlass::field_name (int index) const { return field(index).name(constants()); } > 50: inline Symbol* InstanceKlass::field_signature (int index) const { return field(index).signature(constants()); } There should not be spaces between a method name and the opening `(`. I'm really not a fine of this kind of alignment. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12855 From lmesnik at openjdk.org Fri Mar 17 00:02:12 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 00:02:12 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v4] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed test and comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/aa12782b..47df1034 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=02-03 Stats: 17 lines in 2 files changed: 11 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From lmesnik at openjdk.org Fri Mar 17 00:02:38 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 00:02:38 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v3] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> <442V2D4DoDQ4AOZyi4o-l-SEVx85z-KYeFGwDw5hJjM=.5b686eee-802a-4a6c-bce3-a128061fbaf5@github.com> Message-ID: <5TOdkPxx5AoxojXZvlzIBNo_oW91WpmZ_ksO7zu9j2U=.a033cc77-6e4d-450a-bba8-3dfd018a9956@github.com> On Thu, 16 Mar 2023 06:19:14 GMT, Thomas Stuefe wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> comments added > > That also affects OutputAnalyzer, right? Does this affect parsing or is this only printing? > > Anyway, patch looks good to me, modulo of what David wrote. If you fix his remarks, its good to me. @tstuefe Thank you for review. This issue is not related to OutputAnalyzer, I think. However it affects any line processing in ProcessTools.startProcess() and not only printing. ------------- PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Fri Mar 17 04:48:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Mar 2023 04:48:23 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v4] In-Reply-To: References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Fri, 17 Mar 2023 00:02:12 GMT, Leonid Mesnik wrote: >> The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test and comments One minor correction in the test otherwise looks good. Thanks. test/lib-test/jdk/test/lib/process/ProcessToolsLastLineTest.java line 57: > 55: test("\nARG1"); > 56: test("\nARG1\n"); > 57: test("ARG1/n"); Sorry there was a typo in my suggestion - should be "ARG1\n" ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/13034 From dholmes at openjdk.org Fri Mar 17 04:50:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Mar 2023 04:50:21 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 09:33:10 GMT, Varada M wrote: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) Hotspot changes, including tests, require two reviewers. I'll try to get someone else to review and sponsor once done. ------------- PR: https://git.openjdk.org/jdk/pull/12970 From dholmes at openjdk.org Fri Mar 17 05:40:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Mar 2023 05:40:23 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > load_klass now emits null check and other platforms supported If we read `null_check` as "maybe perform a null check" then I can imagine there are places where we definitely do not need a null check and so can elide the call. However, I am far more skeptical there there are places where `null_check` does nothing and we are actually missing a null check - that seems unlikely (not impossible of course). And it may be that people see `null_check` and don't realize they need to read it as `maybe perform a null check` and so have used the wrong code, but ... Given the very recent changes to `load_klass_null_check` I think we need some input from @rkennke and @coleenp . ------------- PR: https://git.openjdk.org/jdk/pull/13026 From stuefe at openjdk.org Fri Mar 17 05:42:21 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Mar 2023 05:42:21 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 09:33:10 GMT, Varada M wrote: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) @varada1110 Ouch, thank you for finding that. Let's see how many tests now start failing :-/ Could a slightly more elegant patch not be to change the condition after the loop not from < if (!positivePatternStack.isEmpty()) { > if (currentPositivePattern != nullptr) { ? But I leave that up to you. Patch is also fine in its current form. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12970 From lmesnik at openjdk.org Fri Mar 17 05:47:08 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 05:47:08 GMT Subject: RFR: 8303697: ProcessTools doesn't print last line of process output [v5] In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: typo fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13034/files - new: https://git.openjdk.org/jdk/pull/13034/files/47df1034..a1d7be0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13034&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13034/head:pull/13034 PR: https://git.openjdk.org/jdk/pull/13034 From rkennke at openjdk.org Fri Mar 17 06:18:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 17 Mar 2023 06:18:24 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > load_klass now emits null check and other platforms supported I am pretty sure that the changes are not quite right. needs_explicit_null_check() checks whether we must emit an *explicit* null-check, or else if we could go with an *implicit* null-check. Implicit null checks plant some debug info (iirc) and don't emit any actual code to do the null-check. So what you see here, no code being emitted for null-check, is not necessarily wrong. Instead, it lets the SIGSEGV happen and then the fault-handler will kick in and determine what to do with it, usually throwing an NPE. What the change does is basically turn a bunch of implicit null checks into explicit null-checks. At the very least, this is less efficient than doing implicit null-checks. And this being in load_klass() I suspect the impact could be quite significant. The part that I am missing is the motivation for the changes. Have you observed situations where we don't throw an NPE where we should, and crash with a SEGV instead? This would be what I expect when a null-check is really missing in the sense that not even implicit null-checks work. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From duke at openjdk.org Fri Mar 17 08:52:52 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 17 Mar 2023 08:52:52 GMT Subject: RFR: 8301684: Fix test code to not get finalizer deprecation warnings [v3] In-Reply-To: References: Message-ID: On Wed, 15 Mar 2023 10:19:08 GMT, Afshin Zafari wrote: >> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). >> Briefly: >> 1. An instance of `Cleaner` (`java.lang.ref`) is created. >> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). >> 3. Write code in the callback to do other cleanings. >> >> >> Cleaner c = new Cleaner(); >> Cleanable cleanable = c.register(an_obj, a_runnable); >> ... >> //JVM notifies by calling the >> a_runnable.run() {...} >> >> ### Tests >> local: >> vmTestbase/nsk/monitoring/stress/classload >> vmTestbase/nsk/jvmti/AttachOnDemand >> vmTestbase/nsk/jdi/ObjectReference/referringObjects >> vmTestbase/nsk/sysdict >> mach5: tier 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8301684: Fix test code to not get finalizer deprecation warnings Thanks for reviewing this PR. ------------- PR: https://git.openjdk.org/jdk/pull/12968 From jsjolen at openjdk.org Fri Mar 17 10:11:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 17 Mar 2023 10:11:38 GMT Subject: RFR: 8304130: Add runtime/StackGuardPages/TestStackGuardPagesNative.java to ProblemList.txt In-Reply-To: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> References: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> Message-ID: On Tue, 14 Mar 2023 12:19:08 GMT, Johan Sj?len wrote: > This test intermittently fails and it's unlikely that further failures will give us any more information on how to solve the problem. Thanks Dan! ------------- PR: https://git.openjdk.org/jdk/pull/13016 From jsjolen at openjdk.org Fri Mar 17 10:11:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 17 Mar 2023 10:11:38 GMT Subject: Integrated: 8304130: Add runtime/StackGuardPages/TestStackGuardPagesNative.java to ProblemList.txt In-Reply-To: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> References: <9y-av2j4HdSQOx1wGztPFLiJ_zvZWMozbK6Q9bAGSoA=.0ad29b38-0f1b-423e-9398-ac19e5890ce0@github.com> Message-ID: On Tue, 14 Mar 2023 12:19:08 GMT, Johan Sj?len wrote: > This test intermittently fails and it's unlikely that further failures will give us any more information on how to solve the problem. This pull request has now been integrated. Changeset: 620564ac Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/620564ac6152be92c5fa83b474d30a43e698d51e Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8304130: Add runtime/StackGuardPages/TestStackGuardPagesNative.java to ProblemList.txt Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/13016 From duke at openjdk.org Fri Mar 17 13:25:14 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 17 Mar 2023 13:25:14 GMT Subject: Integrated: 8301684: Fix test code to not get finalizer deprecation warnings In-Reply-To: References: Message-ID: <8f6w3oqkaYnrDW4g1hLvIeo3fFZN9Boklv9Rvo4KwPE=.6248d146-32ff-4849-b47d-ae5ee2b15a48@github.com> On Fri, 10 Mar 2023 08:23:45 GMT, Afshin Zafari wrote: > To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()). > Briefly: > 1. An instance of `Cleaner` (`java.lang.ref`) is created. > 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed). > 3. Write code in the callback to do other cleanings. > > > Cleaner c = new Cleaner(); > Cleanable cleanable = c.register(an_obj, a_runnable); > ... > //JVM notifies by calling the > a_runnable.run() {...} > > ### Tests > local: > vmTestbase/nsk/monitoring/stress/classload > vmTestbase/nsk/jvmti/AttachOnDemand > vmTestbase/nsk/jdi/ObjectReference/referringObjects > vmTestbase/nsk/sysdict > mach5: tier 1-5 This pull request has now been integrated. Changeset: 6dd6c15e Author: Afshin Zafari Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/6dd6c15ed4b2a563989e97c5a75634c3e0e7e915 Stats: 116 lines in 2 files changed: 9 ins; 85 del; 22 mod 8301684: Fix test code to not get finalizer deprecation warnings Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12968 From lmesnik at openjdk.org Fri Mar 17 13:49:32 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Mar 2023 13:49:32 GMT Subject: Integrated: 8303697: ProcessTools doesn't print last line of process output In-Reply-To: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> References: <2yj8kBz0HKn3QwV6awfX7bwl1IgBqBiRza-ABtJwCzo=.22255150-b358-4def-88a5-ed2ebc0de129@github.com> Message-ID: On Wed, 15 Mar 2023 05:41:33 GMT, Leonid Mesnik wrote: > The StreamPumper is fixed to process the last line even it is not finishes with '\n' or '\r'. The test included. Testing with tier1-3 also to verify that tests are not broken. This pull request has now been integrated. Changeset: 8d2ebf24 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/8d2ebf248e2884fbf138b603ae82f81bd0926cf3 Stats: 87 lines in 2 files changed: 82 ins; 0 del; 5 mod 8303697: ProcessTools doesn't print last line of process output Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/13034 From fparain at openjdk.org Fri Mar 17 13:51:05 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 17 Mar 2023 13:51:05 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v6] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: Style fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12855/files - new: https://git.openjdk.org/jdk/pull/12855/files/f81337f7..ab57b03a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=04-05 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From duke at openjdk.org Fri Mar 17 14:37:26 2023 From: duke at openjdk.org (Varada M) Date: Fri, 17 Mar 2023 14:37:26 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v2] In-Reply-To: References: Message-ID: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) Varada M has updated the pull request incrementally with one additional commit since the last revision: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12970/files - new: https://git.openjdk.org/jdk/pull/12970/files/a4565483..871b2e42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12970&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12970&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12970.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12970/head:pull/12970 PR: https://git.openjdk.org/jdk/pull/12970 From duke at openjdk.org Fri Mar 17 14:37:27 2023 From: duke at openjdk.org (Varada M) Date: Fri, 17 Mar 2023 14:37:27 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v2] In-Reply-To: References: Message-ID: On Mon, 13 Mar 2023 06:02:03 GMT, Varada M wrote: >> This fix seems correct - thanks. > >> This fix seems correct - thanks. > > Thanks @dholmes-ora for reviewing the changes. > @varada1110 Ouch, thank you for finding that. Let's see how many tests now start failing :-/ > > Could a slightly more elegant patch not be to change the condition after the loop not from > > ``` > < if (!positivePatternStack.isEmpty()) { > > if (currentPositivePattern != null) { > ``` > > ? > > But I leave that up to you. Patch is also fine in its current form. Thank you @tstuefe for the suggestion. I have made the changes please review it ------------- PR: https://git.openjdk.org/jdk/pull/12970 From stuefe at openjdk.org Fri Mar 17 14:53:19 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Mar 2023 14:53:19 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v2] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 14:37:26 GMT, Varada M wrote: >> When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. >> >> This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. >> >> JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. Still good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12970 From aturbanov at openjdk.org Fri Mar 17 14:54:30 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 17 Mar 2023 14:54:30 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v6] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 13:51:05 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Style fixes src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 268: > 266: > 267: Field getField(int index) { > 268: synchronized(this) { nit Suggestion: synchronized (this) { src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 380: > 378: dos.writeShort(accessFlags & (short) JVM_RECOGNIZED_FIELD_MODIFIERS); > 379: > 380: int nameIndex = klass.getFieldNameIndex(index); nit: Suggestion: int nameIndex = klass.getFieldNameIndex(index); ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Fri Mar 17 15:58:35 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 17 Mar 2023 15:58:35 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v7] In-Reply-To: References: Message-ID: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Style fixes - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 - Style fixes - SA and JVMCI fixes - Fixes includes and style - SA additional caching from Chris Plummer - Addressing comments from first reviews - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 - Reimplementation of FieldInfo as an unsigned5 stream ------------- Changes: https://git.openjdk.org/jdk/pull/12855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12855&range=06 Stats: 1790 lines in 54 files changed: 927 ins; 483 del; 380 mod Patch: https://git.openjdk.org/jdk/pull/12855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12855/head:pull/12855 PR: https://git.openjdk.org/jdk/pull/12855 From jcking at openjdk.org Fri Mar 17 17:24:42 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 17:24:42 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback Message-ID: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. This change also upgrades and refactors Chunk to use this facility. **Observations** NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. ------------- Commit messages: - Reorder ChunkPoolSize so NONE is 0 - Add support for malloc size feedback Changes: https://git.openjdk.org/jdk/pull/13081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304421 Stats: 376 lines in 5 files changed: 262 ins; 35 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 17:28:56 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 17:28:56 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v2] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades and refactors Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Adjust comment Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/9ae4ea60..e0d87ec0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 17:36:46 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 17:36:46 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v3] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: <8dFSYd0TuOoIqG-LreHPcGu7TethiCNz5pn-E0N4gFs=.162c433d-f663-4210-bbb2-9873c8df17fb@github.com> > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades and refactors Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Handle size overflow Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/e0d87ec0..f5037c8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=01-02 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From coleenp at openjdk.org Fri Mar 17 18:22:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Mar 2023 18:22:05 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> Message-ID: On Tue, 14 Mar 2023 14:04:40 GMT, Coleen Phillimore wrote: >> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 >> and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 >> >> Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Thanks David for the review and help clarifying the wording of the CSR and release note. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From fparain at openjdk.org Fri Mar 17 18:48:34 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 17 Mar 2023 18:48:34 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> Message-ID: <9SL3PsH8kghZEpg5sE9UVuvZNk-5lZ3YXsL3VB59uGg=.020a9ade-d54e-468e-a88f-af0c27c3c308@github.com> On Tue, 14 Mar 2023 14:04:40 GMT, Coleen Phillimore wrote: >> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 >> and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 >> >> Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Marked as reviewed by fparain (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12974 From coleenp at openjdk.org Fri Mar 17 18:59:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Mar 2023 18:59:34 GMT Subject: RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> <3y9tUxyJtCEWMHqEq3QauckGaLf-7lHZDhIJg9kB5Sg=.c745e8fb-3989-4af0-8349-59a8253687bb@github.com> Message-ID: On Tue, 14 Mar 2023 14:04:40 GMT, Coleen Phillimore wrote: >> This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 >> and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 >> >> Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Thank you Fred. ------------- PR: https://git.openjdk.org/jdk/pull/12974 From coleenp at openjdk.org Fri Mar 17 18:59:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Mar 2023 18:59:35 GMT Subject: Integrated: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> References: <9xWEpicRab-CaMZSZvkLUW_U3Tp4d2k-PUkan1sG-h8=.95e7365e-a06c-434c-8e45-a6c5324167a6@github.com> Message-ID: On Fri, 10 Mar 2023 13:41:15 GMT, Coleen Phillimore wrote: > This change removes the JVM code and option (default off) to synchronize class loading for non-parallel capable class loading. For more information see: https://bugs.openjdk.org/browse/JDK-8295673 > and Release Note for the option in 20: https://bugs.openjdk.org/browse/JDK-8296446 > > Now Release Note for removal: https://bugs.openjdk.org/browse/JDK-8303967 > > Tested with tier1-7. This pull request has now been integrated. Changeset: 932be354 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/932be3542d3d82b7da76ef3b82bf76231daf2aa6 Stats: 164 lines in 10 files changed: 1 ins; 147 del; 16 mod 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders Reviewed-by: dholmes, fparain ------------- PR: https://git.openjdk.org/jdk/pull/12974 From stuefe at openjdk.org Fri Mar 17 19:03:52 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Mar 2023 19:03:52 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v3] In-Reply-To: <8dFSYd0TuOoIqG-LreHPcGu7TethiCNz5pn-E0N4gFs=.162c433d-f663-4210-bbb2-9873c8df17fb@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> <8dFSYd0TuOoIqG-LreHPcGu7TethiCNz5pn-E0N4gFs=.162c433d-f663-4210-bbb2-9873c8df17fb@github.com> Message-ID: On Fri, 17 Mar 2023 17:36:46 GMT, Justin King wrote: >> Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. >> >> This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. >> >> This change also upgrades and refactors Chunk to use this facility. >> >> **Observations** >> >> NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Handle size overflow > > Signed-off-by: Justin King Hi, some initial thoughts. I find using excess memory in this manner quite scary. It depends on the implementation correctly not using what it reports. Eg glibc malloc_usable_size comes with a warning label of "this is bad practice". Practically speaking we now treat new paths, which are UB, and may trigger paths in libcs that are not well tested. The gains are probably not large enough to justify this risk. We could probably just resize arena chunks correctly to page sizes or power of two sizes; much simpler that way. There could be some merit in collecting this number and reporting it. But probably not for the end user. Since the real cost of malloc comprises many parts, and overhead of outstanding allocations is just a part of that. Retention size and size of side structures are often more significant. So we would report just an arbitrary part of a larger, unknown whole. One more number to confuse folks, but ultimately not that helpful. Note that we already report libc overhead as a whole. There could be a use case for hotspot devs to highlight particularly "unhappy" allocation sizes. I fear that the number of actionable call sites would be small, though, since the vast majority of allocations come from new and depend on object sizes. That leaves us with buffer allocations, which are usually already power two-sized. Lunping refactoring together with functional changes does not help. Makes it harder to spot the functional changes. Refactoring can be done in separate RFEs if necessary. Since refactoring is often a matter of opinion, it's also fairer to discuss them separately from functional changes. More thoughts: - It is unspecified what the effect should be on NMT allocation guards. Would the guard be added to the user-requested size or to the actual size? The former would render this improvement pointless; the latter makes me personally unhappy since we lose our ability to catch off by one overwrites. This needs to be specified, and we need regression tests for this. - Speaking of it, there are no tests. - The duplication of code in NMTPreInit is just plain bad, as is the duplication of os::free in os.cpp. That said, I don't get the point of free_sized. Why is this needed? - Platform-dependent changes should go into their respective platform folders - Does muslc support malloc_usable_size? If not, pls make your code conditional for glibc (see e.g. the trim coding in the linux branch) Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 19:57:58 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 19:57:58 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v3] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> <8dFSYd0TuOoIqG-LreHPcGu7TethiCNz5pn-E0N4gFs=.162c433d-f663-4210-bbb2-9873c8df17fb@github.com> Message-ID: On Fri, 17 Mar 2023 18:58:10 GMT, Thomas Stuefe wrote: > Hi, > > some initial thoughts. > > I find using excess memory in this manner quite scary. It depends on the implementation correctly not using what it reports. Eg glibc malloc_usable_size comes with a warning label of "this is bad practice". Practically speaking we now treat new paths, which are UB, and may trigger paths in libcs that are not well tested. The gains are probably not large enough to justify this risk. Any implementation returning an invalid size from `malloc_usable_size` is a broken implementation and has no business existing or being supported. glibc `malloc_usable_size` man pages have no such warning, they do have the following quote `Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation.` The warning is there so that callers do not rely on any specific size being returned other than it being at least the original request size. Two different allocations for the same size could have different excess bytes, so make no assumptions. Size feedback is likely being added to operator new in the next version of C++ where a tuple will be returned containing the pointer and size, C has yet to follow suite but likely will in the future. At which point that could be used. > > We could probably just resize arena chunks correctly to page sizes or power of two sizes; much simpler that way. That would not work and would still have waste. It is heavily dependent on the underlying `malloc()` implementation which is free to change. For example if you request exactly a page from glibc `malloc()` your're likely going to get more than that. Whether power-of-two will work also depends on the implementation. > > Lunping refactoring together with functional changes does not help. Makes it harder to spot the functional changes. Refactoring can be done in separate RFEs if necessary. Since refactoring is often a matter of opinion, it's also fairer to discuss them separately from functional changes. > > More thoughts: > > * It is unspecified what the effect should be on NMT allocation guards. Would the guard be added to the user-requested size or to the actual size? The former would render this improvement pointless; the latter makes me personally unhappy since we lose our ability to catch off by one overwrites. This needs to be specified, and we need regression tests for this. Its the latter. The size is now the actual size. The point of size feedback is "allocate at least N bytes, then tell me how much you actually allocated". I'll work on adding some tests. > * Speaking of it, there are no tests. > * The duplication of code in NMTPreInit is just plain bad, as is the duplication of os::free in os.cpp. That said, I don't get the point of free_sized. Why is this needed? free_sized is in C23 and is an optimization for many `malloc()` implementations that allows free to be faster. It's the same rationale as having sized delete in C++. If the size is known, the implementation can skip having to determine the size in order to do the free. That said I could probably try to combine them into a single implementation under the hood. > * Platform-dependent changes should go into their respective platform folders > * Does muslc support malloc_usable_size? If not, pls make your code conditional for glibc (see e.g. the trim coding in the linux branch) Yes it supports it. ------------- PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 20:01:43 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 20:01:43 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v4] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades and refactors Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix compilation on x86 Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/f5037c8c..0d807ce1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 20:08:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 20:08:41 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v5] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades and refactors Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Undo some optional refactoring Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/0d807ce1..ed27c217 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=03-04 Stats: 27 lines in 2 files changed: 0 ins; 13 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From jcking at openjdk.org Fri Mar 17 20:15:48 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 20:15:48 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v6] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Consolidate duplicate code Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/ed27c217..6f3e0eb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=04-05 Stats: 137 lines in 2 files changed: 44 ins; 82 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From fparain at openjdk.org Fri Mar 17 20:19:39 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 17 Mar 2023 20:19:39 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v7] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:58:35 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Style fixes > - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 > - Style fixes > - SA and JVMCI fixes > - Fixes includes and style > - SA additional caching from Chris Plummer > - Addressing comments from first reviews > - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 > - Reimplementation of FieldInfo as an unsigned5 stream Chris, Doug, thank you for your reviews and your help. Coleen, David, Andrey, thank you for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12855 From fparain at openjdk.org Fri Mar 17 20:22:48 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 17 Mar 2023 20:22:48 GMT Subject: Integrated: 8292818: replace 96-bit representation for field metadata with variable-sized streams In-Reply-To: References: Message-ID: <1g-MNikg2bzX02U4IDcsKO4nGqPUWZI-77gTMrmQtlA=.5a102edd-69f2-4cd8-9738-fe5075f02f2c@github.com> On Fri, 3 Mar 2023 14:50:34 GMT, Frederic Parain wrote: > Please review this change re-implementing the FieldInfo data structure. > > The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. > > The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). > > More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 > > Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. > > The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. > > Tested with mach5, tier 1 to 7. > > Thank you. This pull request has now been integrated. Changeset: bfb812a8 Author: Frederic Parain URL: https://git.openjdk.org/jdk/commit/bfb812a8ff8bca70aed7695c73f019ae66ac6f33 Stats: 1790 lines in 54 files changed: 927 ins; 483 del; 380 mod 8292818: replace 96-bit representation for field metadata with variable-sized streams Co-authored-by: John R Rose Co-authored-by: Chris Plummer Reviewed-by: dholmes, coleenp, cjplummer, dnsimon ------------- PR: https://git.openjdk.org/jdk/pull/12855 From jcking at openjdk.org Fri Mar 17 21:39:37 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 17 Mar 2023 21:39:37 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v7] In-Reply-To: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: > Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. > > This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. > > This change also upgrades Chunk to use this facility. > > **Observations** > > NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. Justin King has updated the pull request incrementally with one additional commit since the last revision: Undo more refactoring Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13081/files - new: https://git.openjdk.org/jdk/pull/13081/files/6f3e0eb4..b434fe40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13081&range=05-06 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13081/head:pull/13081 PR: https://git.openjdk.org/jdk/pull/13081 From matsaave at openjdk.org Fri Mar 17 22:09:05 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 17 Mar 2023 22:09:05 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v2] In-Reply-To: <8f3tmysWFvae4frIvPZOQg1LoX5nXWyQzAqz8ZFHM0c=.127fb8ec-ac87-403b-9330-378c61939737@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> <-jZ453fBN1vWZzsw3k1V838Ma79TPyHicV23MC2Mr8I=.91123cad-5381-4fe1-bf0e-3ab5a48a097e@github.com> <8f3tmysWFvae4frIvPZOQg1LoX5nXWyQzAqz8ZFHM0c=.127fb8ec-ac87-403b-9330-378c61939737@github.com> Message-ID: On Wed, 1 Mar 2023 21:35:21 GMT, Matias Saavedra Silva wrote: >> src/hotspot/share/runtime/arguments.cpp line 2927: >> >>> 2925: UseSharedSpaces = false; >>> 2926: RequireSharedSpaces = false; >>> 2927: } >> >> I think you should call `no_shared_spaces()` instead. That way, the VM will print an error message and exit if `-Xshare:on` is specified. > > Adding `no_shared_spaces()` here makes sense but it results in a duplicate output. I will move this check up to the caller of this method to avoid redundant logs. Fixed! ------------- PR: https://git.openjdk.org/jdk/pull/12705 From coleenp at openjdk.org Fri Mar 17 22:17:21 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Mar 2023 22:17:21 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v3] In-Reply-To: References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: On Wed, 1 Mar 2023 21:10:49 GMT, Matias Saavedra Silva wrote: >> CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Moved check for exploded JDK This seems fine. It appears that Ioi's comments were also addressed. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12705 From matsaave at openjdk.org Fri Mar 17 22:37:18 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 17 Mar 2023 22:37:18 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v4] In-Reply-To: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: <7gQI5R6HIdQqMUX_C3PGPHAGl-c2qI17G_7Dx124qek=.98ce6645-6982-4bd5-baf6-bb036cd5b637@github.com> > CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into explodedjdk - Moved check for exploded JDK - Replaced condition with assert - 8301715: CDS should be disabled in exploded JDK ------------- Changes: https://git.openjdk.org/jdk/pull/12705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12705&range=03 Stats: 11 lines in 2 files changed: 6 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12705.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12705/head:pull/12705 PR: https://git.openjdk.org/jdk/pull/12705 From jsjolen at openjdk.org Sat Mar 18 14:57:14 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 18 Mar 2023 14:57:14 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting Message-ID: Hi, The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: public class Test { public static void main(String[] args) { } } These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. os::commit old | new | new / old 935238 | 578979 | 0.62 os::reserve old | new | new / old 53628 | 21825 | 0.41 There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. ------------- Commit messages: - Fix tests - Delay work through a worklist Changes: https://git.openjdk.org/jdk/pull/13088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304442 Stats: 127 lines in 5 files changed: 97 ins; 1 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13088.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13088/head:pull/13088 PR: https://git.openjdk.org/jdk/pull/13088 From jsjolen at openjdk.org Sat Mar 18 14:57:14 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 18 Mar 2023 14:57:14 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. > > > os::commit > old | new | new / old > 935238 | 578979 | 0.62 > os::reserve > old | new | new / old > 53628 | 21825 | 0.41 > > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. Here are the call graphs for the new `os::commit` and the old `os::commit`. Most of the new method is inlined. ![commit_new](https://user-images.githubusercontent.com/103041674/226113355-685ed3af-2095-4c81-8e78-011afc09d8ea.png) ![commit_old](https://user-images.githubusercontent.com/103041674/226113357-c539eabd-17da-4bc3-8893-36d3c3bbc3d2.png) ------------- PR: https://git.openjdk.org/jdk/pull/13088 From jsjolen at openjdk.org Sat Mar 18 16:34:19 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 18 Mar 2023 16:34:19 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: <-pvJ2UhLFIXPrZsMmiDWrfCF1T6VZSAwY-L6sMhRdCI=.44602d06-d8e8-4cc3-83be-f4efd1daaae1@github.com> On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with `-XX:NativeMemoryTracking=detail` and with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. > > > os::commit > old | new | new / old > 935238 | 578979 | 0.62 > os::reserve > old | new | new / old > 53628 | 21825 | 0.41 > > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. src/hotspot/share/services/virtualMemoryTracker.hpp line 389: > 387: }; > 388: Tag tag; > 389: void* addr; size_t size; Switch `addr` from `void*` to `address` to make it clear that we don't intend to dereference this pointer. ------------- PR: https://git.openjdk.org/jdk/pull/13088 From jsjolen at openjdk.org Sat Mar 18 16:51:28 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 18 Mar 2023 16:51:28 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. Passes tier1 and tier2. @tstuefe , @gerard-ziemski. I think you'll be interested in this. ------------- PR: https://git.openjdk.org/jdk/pull/13088 From stuefe at openjdk.org Sun Mar 19 07:55:18 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 19 Mar 2023 07:55:18 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. Hi Johan, that is an interesting idea, but I am not convinced, which is a pity since the PR is well prepared and the callgraphs are nice. A problem and a question of usefulness: The problem is that you really don't want to defer NMT accounting to report time. At the time of the report, you may be out of memory or out of time, or both. E.g., during error reporting as a result of a native OOM. In these situations, NMT reports are very useful, but they must be fast and should not rely on malloc. Malloc may not work anymore, or it may hang. I argue that reports are too expensive today and should be made snappier and cheaper. Another context where NMT reports are called is as part of JFR value sampling. Again, in the JFR sampler thread, you don't want to spend much time processing deferred allocations. There are other examples, at least in SAP's downstream VM. I think getting NMT numbers should be quick and painless, and possible in any situation. The usefulness question: Either mapping management in NMT is hot, or it isn't. If it isn't, there is no point in optimizing it. If it *is* hot, e.g., because you call os::commit a million times (?), a queue may not work as well as you think. You now accumulate an ever-growing footprint for the queue. So you need to dump the queue at some point. If you do, you lose the advantage of deferring. If you don't dump, you now have a memory leak essentially, and reporting will take a lot longer. ----- I keep thinking that the real problem here is that virtual memory management in NMT is not optimal. And that we should make it more efficient and hopefully simpler. Side note, the list of mappings should never be unbearably large. Because it mirrors mappings on the OS side, and if we have millions of them, we have an address space fragmentation problem. But usually, the list is quite small. Low hundreds or thousands of entries. Here are some ideas for simplification and for making NMT vm registration cheaper: - The number of mappings is probably dominated by the number of threads. Because all other users of virtual memory (GC, metaspace, ...) typically don't fragment address space too much. But if we have 10000 threads, we have as 10000 stacks + 10000 guard pages. I believe we currently keep stack information piggybacked in NMT as virtual memory? If so, this is double accounting. Because we already have a perfectly valid list of threads, and the threads know where their stacks are. Instead of walking the list of mappings to account for stacks, we could just walk the original list of threads to get the stack sizes. The NMT list of mappings would be smaller, making insertion and walking cheaper. - We keep mappings in NMT in a linked list. That is not the best way for walking nor for sorted insert. Walking causes cache misses, and sorted inserting is O(n). I keep thinking the best data structure would be a binary tree of address points, which may be too complex a rewrite. But we could experiment with a flat array. Inserting would be more expensive - you need to push follow-up entries out of the way - but inserting and walking are now much more cache friendly. Even more so if we condense the mapping information. I think 16 bytes per entry should be enough. 8 byte start pointer, 4 byte number of pages (gives you a total range of 8TB per mapping), 4 byte for the meta info (is committed, is reserved, NMT flag...). So now you have a flat array of 16-byte-entries per mapping. That may be faster for inserting/walking than todays linked list, even with the more complex insert. These are just some ideas; I have not tried them, they may not pan out as I think. The original author of NMT did a lot of investigation, and I may overlook something. I'm interested in other opinions. Sorry for not liking your deferral idea! Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/13088 From jsjolen at openjdk.org Sun Mar 19 13:51:18 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sun, 19 Mar 2023 13:51:18 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. Hi Thomas, thanks for the in-depth review! Alright, if it's a hard requirement that *reporting* must be fast and not allocate memory, then this particular solution is a deal breaker. Regarding your ideas: 1. `commit_memory` is often called by metaspace, but `pd_create_stackguard_pages` is a close 2nd. 2. I actually think that we can get most of the gains from this PR by just allocating the linked list in an arena instead (`FixedItemArray` :)?). A large amount of the runtime is spent on doing these `NativeCallStack`s during node allocation in detailed mode, and malloc:ing is potentially (I'd measure it) costly in summary mode. The rest of this is commenting on the rest of your points. >The usefulness question: Either mapping management in NMT is hot, or it isn't. If it isn't, there is no point in optimizing it. If we have 100 things in the JVM that are up to 17x slower than they need be and their computations are spread over an entire process duration, then how will you figure that any of them are hot? It's hard to discern what the total performance cost is for these things. >If it is hot, e.g., because you call os::commit a million times (?), a queue may not work as well as you think. You now accumulate an ever-growing footprint for the queue. So you need to dump the queue at some point. If you do, you lose the advantage of deferring. If you don't dump, you now have a memory leak essentially, and reporting will take a lot longer. It's not any worse than the memory leak that would exist from keeping the linked list alive. But yes, it could be useful to dump the queue when it grows too large. ------------- PR: https://git.openjdk.org/jdk/pull/13088 From dholmes at openjdk.org Mon Mar 20 02:19:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Mar 2023 02:19:22 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v2] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 14:37:26 GMT, Varada M wrote: >> When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. >> >> This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. >> >> JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. So checking for null-ness covers the case of the last pattern not matching, regardless of whether there are any other patterns still to be checked. Yep that logic seems fine. A nit with the explanatory comment though. test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 133: > 131: lineNo++; > 132: } > 133: // check if current pattern is NULL then pattern matches else throw RuntimeException Sorry this doesn't read very clearly to me. Suggestion: // If the current pattern is not null then it didn't match Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12970 From dholmes at openjdk.org Mon Mar 20 02:42:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Mar 2023 02:42:21 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v3] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> <8dFSYd0TuOoIqG-LreHPcGu7TethiCNz5pn-E0N4gFs=.162c433d-f663-4210-bbb2-9873c8df17fb@github.com> Message-ID: On Fri, 17 Mar 2023 19:55:19 GMT, Justin King wrote: >> Hi, >> >> some initial thoughts. >> >> I find using excess memory in this manner quite scary. It depends on the implementation correctly not using what it reports. Eg glibc malloc_usable_size comes with a warning label of "this is bad practice". Practically speaking we now treat new paths, which are UB, and may trigger paths in libcs that are not well tested. The gains are probably not large enough to justify this risk. >> >> We could probably just resize arena chunks correctly to page sizes or power of two sizes; much simpler that way. >> >> There could be some merit in collecting this number and reporting it. But probably not for the end user. Since the real cost of malloc comprises many parts, and overhead of outstanding allocations is just a part of that. Retention size and size of side structures are often more significant. So we would report just an arbitrary part of a larger, unknown whole. One more number to confuse folks, but ultimately not that helpful. Note that we already report libc overhead as a whole. >> >> There could be a use case for hotspot devs to highlight particularly "unhappy" allocation sizes. I fear that the number of actionable call sites would be small, though, since the vast majority of allocations come from new and depend on object sizes. That leaves us with buffer allocations, which are usually already power two-sized. >> >> Lunping refactoring together with functional changes does not help. Makes it harder to spot the functional changes. Refactoring can be done in separate RFEs if necessary. Since refactoring is often a matter of opinion, it's also fairer to discuss them separately from functional changes. >> >> More thoughts: >> >> - It is unspecified what the effect should be on NMT allocation guards. Would the guard be added to the user-requested size or to the actual size? The former would render this improvement pointless; the latter makes me personally unhappy since we lose our ability to catch off by one overwrites. This needs to be specified, and we need regression tests for this. >> - Speaking of it, there are no tests. >> - The duplication of code in NMTPreInit is just plain bad, as is the duplication of os::free in os.cpp. That said, I don't get the point of free_sized. Why is this needed? >> - Platform-dependent changes should go into their respective platform folders >> - Does muslc support malloc_usable_size? If not, pls make your code conditional for glibc (see e.g. the trim coding in the linux branch) >> >> Cheers, Thomas > >> Hi, >> >> some initial thoughts. >> >> I find using excess memory in this manner quite scary. It depends on the implementation correctly not using what it reports. Eg glibc malloc_usable_size comes with a warning label of "this is bad practice". Practically speaking we now treat new paths, which are UB, and may trigger paths in libcs that are not well tested. The gains are probably not large enough to justify this risk. > > Any implementation returning an invalid size from `malloc_usable_size` is a broken implementation and has no business existing or being supported. > > glibc `malloc_usable_size` man pages have no such warning, they do have the following quote `Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation.` The warning is there so that callers do not rely on any specific size being returned other than it being at least the original request size. Two different allocations for the same size could have different excess bytes, so make no assumptions. > > Size feedback is likely being added to operator new in the next version of C++ where a tuple will be returned containing the pointer and size, C has yet to follow suite but likely will in the future. At which point that could be used. > >> >> We could probably just resize arena chunks correctly to page sizes or power of two sizes; much simpler that way. > > That would not work and would still have waste. It is heavily dependent on the underlying `malloc()` implementation which is free to change. For example if you request exactly a page from glibc `malloc()` your're likely going to get more than that. Whether power-of-two will work also depends on the implementation. > >> >> Lunping refactoring together with functional changes does not help. Makes it harder to spot the functional changes. Refactoring can be done in separate RFEs if necessary. Since refactoring is often a matter of opinion, it's also fairer to discuss them separately from functional changes. >> >> More thoughts: >> >> * It is unspecified what the effect should be on NMT allocation guards. Would the guard be added to the user-requested size or to the actual size? The former would render this improvement pointless; the latter makes me personally unhappy since we lose our ability to catch off by one overwrites. This needs to be specified, and we need regression tests for this. > > Its the latter. The size is now the actual size. The point of size feedback is "allocate at least N bytes, then tell me how much you actually allocated". I'll work on adding some tests. > >> * Speaking of it, there are no tests. >> * The duplication of code in NMTPreInit is just plain bad, as is the duplication of os::free in os.cpp. That said, I don't get the point of free_sized. Why is this needed? > > free_sized is in C23 and is an optimization for many `malloc()` implementations that allows free to be faster. It's the same rationale as having sized delete in C++. If the size is known, the implementation can skip having to determine the size in order to do the free. > > That said I could probably try to combine them into a single implementation under the hood. > >> * Platform-dependent changes should go into their respective platform folders >> * Does muslc support malloc_usable_size? If not, pls make your code conditional for glibc (see e.g. the trim coding in the linux branch) > > Yes it supports it. @jcking so is the basic idea that if our own internal allocation mechanism wants to allocate a chunk of size M, and what malloc actually gives back is a chunk of size N (N>M), then we just mark the size of our chunk as N instead of M, thus taking full advantage of what malloc returns? How often do we get back a significant extra amount of memory? I can understand the returned about being rounded up based on page size, or alignment constraints, but I'd expect those to be minimal (else surely it is a very poor malloc implementation!). And I'd expect our own allocators to use similar rounding approaches themselves anyway. ------------- PR: https://git.openjdk.org/jdk/pull/13081 From duke at openjdk.org Mon Mar 20 06:44:55 2023 From: duke at openjdk.org (Varada M) Date: Mon, 20 Mar 2023 06:44:55 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v3] In-Reply-To: References: Message-ID: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) Varada M has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12970/files - new: https://git.openjdk.org/jdk/pull/12970/files/871b2e42..22c1843f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12970&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12970&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12970.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12970/head:pull/12970 PR: https://git.openjdk.org/jdk/pull/12970 From duke at openjdk.org Mon Mar 20 06:44:56 2023 From: duke at openjdk.org (Varada M) Date: Mon, 20 Mar 2023 06:44:56 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v2] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 02:15:09 GMT, David Holmes wrote: >> Varada M has updated the pull request incrementally with one additional commit since the last revision: >> >> 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. > > test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUtils.java line 133: > >> 131: lineNo++; >> 132: } >> 133: // check if current pattern is NULL then pattern matches else throw RuntimeException > > Sorry this doesn't read very clearly to me. Suggestion: > > // If the current pattern is not null then it didn't match > > Thanks Thank you @dholmes-ora for the suggestion. I have updated the comment. Please review the change. ------------- PR: https://git.openjdk.org/jdk/pull/12970 From stuefe at openjdk.org Mon Mar 20 13:40:52 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Mar 2023 13:40:52 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v3] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 06:44:55 GMT, Varada M wrote: >> When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. >> >> This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. >> >> JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > comment Still good to go ------------- PR: https://git.openjdk.org/jdk/pull/12970 From coleenp at openjdk.org Mon Mar 20 14:55:52 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 20 Mar 2023 14:55:52 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v4] In-Reply-To: <7gQI5R6HIdQqMUX_C3PGPHAGl-c2qI17G_7Dx124qek=.98ce6645-6982-4bd5-baf6-bb036cd5b637@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> <7gQI5R6HIdQqMUX_C3PGPHAGl-c2qI17G_7Dx124qek=.98ce6645-6982-4bd5-baf6-bb036cd5b637@github.com> Message-ID: On Fri, 17 Mar 2023 22:37:18 GMT, Matias Saavedra Silva wrote: >> CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. > > Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into explodedjdk > - Moved check for exploded JDK > - Replaced condition with assert > - 8301715: CDS should be disabled in exploded JDK Still looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12705 From matsaave at openjdk.org Mon Mar 20 15:07:47 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 20 Mar 2023 15:07:47 GMT Subject: RFR: 8301715: CDS should be disabled in exploded JDK [v3] In-Reply-To: References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: <1iPY9heRLGUsLk7aoeMtvzsFPfc9J5JaXIi2ozLne-k=.cd74b155-4308-4b60-98f5-f72def8c61b7@github.com> On Wed, 1 Mar 2023 22:27:17 GMT, Calvin Cheung wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved check for exploded JDK > > Updates look good. Thanks. Thank you for the reviews @calvinccheung, @iklam , and @coleenp! ------------- PR: https://git.openjdk.org/jdk/pull/12705 From fparain at openjdk.org Mon Mar 20 15:10:07 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 20 Mar 2023 15:10:07 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > load_klass now emits null check and other platforms supported Regarding the motivation of this CR: I filled this RFE because I found the code confusing. When null_check() is called with an offset argument being klass_offset_in_bytes() and length_offset_in_bytes(), it *never* emits an explicit null check. And using this method, or methods calling it might give a false sense of security. For instance, on x86, MacroAssembler::load_klass() and MacroAssembler::load_klass_check_null() emit exactly the same code. So why having two methods, one sounding safer than the other, when in fact, they are doing the same job. I don't think null checks are missing in the code, implicit null checks are doing a really good job, but when I filled the bug, I didn't have time to check that it was the case for all locations where it was statically known that null_check() would not produce an explicit null check. So the motivation is a code cleanup, and not fixing some missing null checks. ------------- PR: https://git.openjdk.org/jdk/pull/13026 From jcking at openjdk.org Mon Mar 20 15:16:51 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 15:16:51 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v7] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: On Fri, 17 Mar 2023 21:39:37 GMT, Justin King wrote: >> Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. >> >> This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. >> >> This change also upgrades Chunk to use this facility. >> >> **Observations** >> >> NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Undo more refactoring > > Signed-off-by: Justin King #include #include constexpr size_t kMaxSize = 1024 * 1024; int main() { for (size_t s = 2; s < kMaxSize; s *= 2) { void* p = malloc(s); size_t u = malloc_usable_size(p); std::cout << "requested_size: " << s << " actual_size: " << u << " wasted_size: " << u - s << std::endl; free(p); } } On FreeBSD and macOS there is 0 wasted space for power of 2 once you are past something like 32 bytes. This is not the case on Linux with glibc. Its possible to get lots of wasted space (4 kb) over 65 kb. And this is configurable. I am not sure about Windows. This is why instead of trying to guess the best fit, like the chunk sizes, do, its better to just ask the implementation. This is free to change at any point and from version to version. glibc will infact coalesce free blocks together. Sometimes there will be less wasted space and sometimes there is more. Try removing the `free` call and you will get slightly different results. People are also free to replace there system malloc implementation with a custom one, and some do. `tcmalloc` operates this way. So even guessing on appropriate sizes for most platforms won't work. ------------- PR: https://git.openjdk.org/jdk/pull/13081 From matsaave at openjdk.org Mon Mar 20 15:24:44 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 20 Mar 2023 15:24:44 GMT Subject: Integrated: 8301715: CDS should be disabled in exploded JDK In-Reply-To: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> References: <7OCN9PsIfLlK3ELKdJ159aHHaMFgMZm7HWeoA-YMd9o=.615afb6b-f0b3-41da-ad6e-3984eb47d0b7@github.com> Message-ID: On Wed, 22 Feb 2023 03:07:46 GMT, Matias Saavedra Silva wrote: > CDS is not supported by the exploded JDK yet it is enabled anyway, leading to guaranteed failure. Now there will be no attempt to map the CDS archive on an exploded build. Verified with tier 1 tests. This pull request has now been integrated. Changeset: eb73fa83 Author: Matias Saavedra Silva Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/eb73fa833cfae24726e081308a595709dfb8f264 Stats: 11 lines in 2 files changed: 6 ins; 5 del; 0 mod 8301715: CDS should be disabled in exploded JDK Reviewed-by: ccheung, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12705 From jcking at google.com Mon Mar 20 15:42:58 2023 From: jcking at google.com (Justin King) Date: Mon, 20 Mar 2023 08:42:58 -0700 Subject: Atomic Message-ID: While messing around with seeing if ThreadSanitizer would be useful in Hotspot, I rewrote runtime/atomic.hpp using compiler intrinsics (__atomic_* on GCC/Clang/XLC, interlocked for MSVC) instead of inline assembly. Inline assembly doesn't get instrumented very well and the compiler cannot optimize it very well. Is there any want for replacing the inline assembly with compiler intrinsics, regardless of ThreadSanitizer? They also have intrinsics that can be used to build optimized implementations of parallel bit set manipulation as well. -- [image: Google Logo] Justin King Software Engineer jcking at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3999 bytes Desc: S/MIME Cryptographic Signature URL: From jcking at openjdk.org Mon Mar 20 16:29:40 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 16:29:40 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros,count_trailing_zeros,population_count}.hpp Message-ID: As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into popcount - Update copyright - Cleanup based on byteswap.hpp - Refactor count_leading_zeros, count_trailing_zeros, and population_count Changes: https://git.openjdk.org/jdk/pull/13103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304539 Stats: 413 lines in 3 files changed: 184 ins; 155 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From stuefe at openjdk.org Mon Mar 20 16:42:42 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Mar 2023 16:42:42 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v7] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: On Fri, 17 Mar 2023 21:39:37 GMT, Justin King wrote: >> Memory allocated by `malloc()` is frequently larger than the size actually requested. Some `malloc()` implementations allow querying this information. This can be useful as an optimization for some use cases, such as an arena allocator, as it allows using the entire memory block. >> >> This change updates `os::malloc()` by appending an additional argument that can request the actual usable size. On platforms that support it, the actual usable size of the allocation returned by `malloc()` will be filled in. Callers should then use `os::free_sized`, as with NMT enabled it can assert that the size is correct. This also is a precursor to eventually supporting `free_sized` from C23, which is an optimization usabled by some `malloc()` implementations to make `free()` quicker. >> >> This change also upgrades Chunk to use this facility. >> >> **Observations** >> >> NMT could use this same facility to keep track of the actual allocated size, instead of the requested size it has today, making it more accurate. Doing so is out of scope for this change. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Undo more refactoring > > Signed-off-by: Justin King Your proposal has costs: - the inherent risk of writing over malloc-allocated boundaries ("Any implementation returning an invalid size from malloc_usable_size is a broken implementation and has no business existing or being supported" sounds good and all but customers with crashing systems won't care if it's us screwing up or the libc maintainers). - The loss of precision of NMT-provided overwrite checks - increased complexity and reviewer churn. There is a ton of things to do and little reviewer time to go around. Do the benefits outweigh these costs? Maybe, but we don't know that since there are no numbers. What we do know is that most small-grained allocations - that could benefit from your change most - are C++ objects with fixed sizes. Leaves those little raw buffers in things like stringStream, and arena chunks. But for arena chunks in particular, it makes sense to discuss alternatives. E.g. we could just re-use the metaspace allocator for hs arenas. Metaspace is a much better arena allocator than hs arenas, which makes sense since Metaspace is the spiritual successor. A variant of that would be to just roll our own allocator for arenas. Allocate chunks via os::reseve/commit_memory, and take care of committing/uncommitting ourselves. That would be trivial to implement. Both examples would solve not only the overhead-per-chunk problem but also the retention problem in glibc and other libc implementations (e.g. AIX, Solaris), which I see as the larger problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13081#issuecomment-1476576364 From jcking at openjdk.org Mon Mar 20 17:25:52 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 17:25:52 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v7] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: On Mon, 20 Mar 2023 16:38:55 GMT, Thomas Stuefe wrote: > Your proposal has costs: > > * the inherent risk of writing over malloc-allocated boundaries ("Any implementation returning an invalid size from malloc_usable_size is a broken implementation and has no business existing or being supported" sounds good and all but customers with crashing systems won't care if it's us screwing up or the libc maintainers). But that is the case for all of libc. `malloc_usable_size` is no different. > * The loss of precision of NMT-provided overwrite checks I fail to see how this is the case. The idea here is allocate at least N, then have `malloc` tell how much it actually gave `M`. M is the actual size of the allocation and what you want. This wouldn't be used except for arena-like implementations or maybe containers where extra size can be used, not fixed size C++ objects. > * increased complexity and reviewer churn. There is a ton of things to do and little reviewer time to go around. Sure, but adding simple size feedback and completely rewriting Arena to use Metaspace allocator are two different things, with the latter being much more complicated. > > Do the benefits outweigh these costs? Maybe, but we don't know that since there are no numbers. What we do know is that most small-grained allocations - that could benefit from your change most - are C++ objects with fixed sizes. Leaves those little raw buffers in things like stringStream, and arena chunks. C++ objects with fixed sizes are not the target here. Only allocations which can make use of the extra space, like arenas or contiguous containers. > > But for arena chunks in particular, it makes sense to discuss alternatives. E.g. we could just re-use the metaspace allocator for hs arenas. Metaspace is a much better arena allocator than hs arenas, which makes sense since Metaspace is the spiritual successor. > > A variant of that would be to just roll our own allocator for arenas. Allocate chunks via os::reseve/commit_memory, and take care of committing/uncommitting ourselves. That would be trivial to implement. > > Both examples would solve not only the overhead-per-chunk problem but also the retention problem in glibc and other libc implementations (e.g. AIX, Solaris), which I see as the larger problem. Doesn't the metaspace allocator have extra logic for garbage collection and limits on the maximum size of an allocation? Its unlikely to out perform a simple arena allocator which allocates chunks of memory and simply increments a pointer in most cases to dole out memory. Additionally all allocations in the arena are extremely short lived typically. Those that are not are very small, such as the arena used for JNI handles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13081#issuecomment-1476644466 From jwaters at openjdk.org Mon Mar 20 17:46:46 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 20 Mar 2023 17:46:46 GMT Subject: RFR: 8304541: Modules THROW_MSG_ should return nullptr instead of JNI_FALSE Message-ID: Cleanup in NPE code to return a proper nullptr instead of JNI_FALSE. JNI_FALSE expands to 0, which technically works as a null pointer here, but this becomes pretty confusing and strange when reading through the code ------------- Commit messages: - Modules THROW_MSG_ should return nullptr instead of JNI_FALSE Changes: https://git.openjdk.org/jdk/pull/13105/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13105&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304541 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13105.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13105/head:pull/13105 PR: https://git.openjdk.org/jdk/pull/13105 From coleenp at openjdk.org Mon Mar 20 18:05:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 20 Mar 2023 18:05:28 GMT Subject: RFR: 8304541: Modules THROW_MSG_ should return nullptr instead of JNI_FALSE In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 17:39:58 GMT, Julian Waters wrote: > Cleanup in NPE code to return a proper nullptr instead of JNI_FALSE. JNI_FALSE expands to 0, which technically works as a null pointer here, but this becomes pretty confusing and strange when reading through the code Looks good, also trivial. I'm surprised there weren't more of these. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13105#pullrequestreview-1349137717 From jwaters at openjdk.org Mon Mar 20 18:16:27 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 20 Mar 2023 18:16:27 GMT Subject: RFR: 8304541: Modules THROW_MSG_ should return nullptr instead of JNI_FALSE In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 17:39:58 GMT, Julian Waters wrote: > Cleanup in NPE code to return a proper nullptr instead of JNI_FALSE. JNI_FALSE expands to 0, which technically works as a null pointer here, but this becomes pretty confusing and strange when reading through the code Thanks Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13105#issuecomment-1476714354 From jwaters at openjdk.org Mon Mar 20 18:16:28 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 20 Mar 2023 18:16:28 GMT Subject: Integrated: 8304541: Modules THROW_MSG_ should return nullptr instead of JNI_FALSE In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 17:39:58 GMT, Julian Waters wrote: > Cleanup in NPE code to return a proper nullptr instead of JNI_FALSE. JNI_FALSE expands to 0, which technically works as a null pointer here, but this becomes pretty confusing and strange when reading through the code This pull request has now been integrated. Changeset: 19f2edd9 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/19f2edd9b7e354cf31df4b7596e6a6eb59b34bf9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8304541: Modules THROW_MSG_ should return nullptr instead of JNI_FALSE Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/13105 From jcking at openjdk.org Mon Mar 20 18:17:12 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 18:17:12 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v2] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix ambiguous call Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/52859de3..729b0c7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=00-01 Stats: 26 lines in 3 files changed: 12 ins; 6 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 18:26:00 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 18:26:00 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v3] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary templating from count_trailing_zeros Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/729b0c7a..e494027f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 18:33:42 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 18:33:42 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v4] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Redo non-templated approach Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/e494027f..c1f4bd9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=02-03 Stats: 46 lines in 1 file changed: 6 ins; 6 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 19:05:59 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 19:05:59 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v5] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove intrinsic specifier for CountOneBits Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/c1f4bd9a..024a6ef7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 19:15:46 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 19:15:46 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v6] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Go back to templating for count_trailing_zeros for consistency Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/024a6ef7..1ee4120a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=04-05 Stats: 71 lines in 1 file changed: 29 ins; 15 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From cslucas at openjdk.org Mon Mar 20 19:23:34 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 20 Mar 2023 19:23:34 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Add support for SR'ing some inputs of merges used for field loads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/3b492d2e..a158ae66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=02-03 Stats: 481 lines in 9 files changed: 292 ins; 117 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From jcking at openjdk.org Mon Mar 20 19:40:23 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 19:40:23 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v7] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add missing #endif Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/1ee4120a..8b36d016 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 20:55:21 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 20:55:21 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v8] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add default template implementation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/8b36d016..01ffca24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=06-07 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 20 21:01:30 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 20 Mar 2023 21:01:30 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v9] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Move template declaration Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/01ffca24..fc392637 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=07-08 Stats: 30 lines in 1 file changed: 15 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From coleenp at openjdk.org Tue Mar 21 00:36:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Mar 2023 00:36:05 GMT Subject: RFR: 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found Message-ID: Removed the test. This test was missing a @compile and can't test what it is trying to test (just gets an OOM). See CR for more details. ------------- Commit messages: - 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found Changes: https://git.openjdk.org/jdk/pull/13110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299494 Stats: 336 lines in 2 files changed: 0 ins; 336 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13110/head:pull/13110 PR: https://git.openjdk.org/jdk/pull/13110 From david.holmes at oracle.com Tue Mar 21 01:23:28 2023 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Mar 2023 11:23:28 +1000 Subject: Atomic In-Reply-To: References: Message-ID: <01c94a6c-f1d1-56ba-920b-13fdad986b36@oracle.com> On 21/03/2023 1:42 am, Justin King wrote: > While messing around with seeing if ThreadSanitizer would be useful in > Hotspot, I rewrote runtime/atomic.hpp using compiler intrinsics > (__atomic_* on GCC/Clang/XLC, interlocked for MSVC) instead of inline > assembly. I assume you mean the platform specific atomic*.hpp files? Inline assembly doesn't get instrumented very well and the > compiler cannot optimize it very well. Is there any want for replacing > the inline assembly with compiler intrinsics, regardless of > ThreadSanitizer? They also have intrinsics that can be used to build > optimized implementations of parallel bit set manipulation as well. Sorry but this just seems like churn to me. First we have to go through the process of establishing the equivalence of the compiler intrinsics with the assembly code. Then make all the changes. Then deal with the potential that some os_cpu code might be compiled by multiple compilers. Then we have to deal with the possibility that the compilers might change behaviour or introduce bugs across releases (yeah these low-level things _should_ be stable but ...). What would we gain by doing any of this? IMO the ideal place we would like to get to is use of C++ atomic operations, but I wouldn't want to go there via use of compiler intrinsics. And I don't know what challenges we would face trying to use C++ atomic ops. Cheers, David > -- > > Google Logo > Justin King > Software Engineer > jcking at google.com > > > From dholmes at openjdk.org Tue Mar 21 02:01:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Mar 2023 02:01:53 GMT Subject: RFR: 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found In-Reply-To: References: Message-ID: On Tue, 21 Mar 2023 00:28:51 GMT, Coleen Phillimore wrote: > Removed the test. This test was missing a @compile and can't test what it is trying to test (just gets an OOM). See CR for more details. I agree. The test is misguided and cannot verify what it thinks it wants to verify. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13110#pullrequestreview-1349607691 From dholmes at openjdk.org Tue Mar 21 02:10:43 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Mar 2023 02:10:43 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. [v3] In-Reply-To: References: Message-ID: <1gjaIdgXxgJ-1DhsSwBsQGZVXWtmmqvIjLZ_ooSvpK4=.56179f5b-f8ff-496f-8912-3932d1280e1f@github.com> On Mon, 20 Mar 2023 06:44:55 GMT, Varada M wrote: >> When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. >> >> This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. >> >> JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) > > Varada M has updated the pull request incrementally with one additional commit since the last revision: > > comment Looks good. Thanks. I will sponsor now. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12970#pullrequestreview-1349612169 From dcubed at openjdk.org Tue Mar 21 02:10:42 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Mar 2023 02:10:42 GMT Subject: RFR: 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found In-Reply-To: References: Message-ID: On Tue, 21 Mar 2023 00:28:51 GMT, Coleen Phillimore wrote: > Removed the test. This test was missing a @compile and can't test what it is trying to test (just gets an OOM). See CR for more details. Thumbs up. Yes, removing the test is the correct way forward. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13110#pullrequestreview-1349612243 From duke at openjdk.org Tue Mar 21 04:54:42 2023 From: duke at openjdk.org (Varada M) Date: Tue, 21 Mar 2023 04:54:42 GMT Subject: RFR: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 04:47:58 GMT, David Holmes wrote: >> When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. >> >> This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. >> >> JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) > > Hotspot changes, including tests, require two reviewers. I'll try to get someone else to review and sponsor once done. > @dholmes-ora The PR has been updated since the change author (@varada1110) issued the `integrate` command - the author must perform this command again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12970#issuecomment-1477278444 From duke at openjdk.org Tue Mar 21 05:49:53 2023 From: duke at openjdk.org (Varada M) Date: Tue, 21 Mar 2023 05:49:53 GMT Subject: Integrated: 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 09:33:10 GMT, Varada M wrote: > When last pattern in deque [positivePatternStack] is not matching in HsErrFile, it comes out of the loop and check whether the positivePatternStack is empty or not, which turns to be empty because the pollFirst() removes the pattern. > > This has been noticed in the TestSigInfoInHsErrFile.java where the segfault address for AIX is set as "0x0*1400" instead of "0xffffffffffffffff", which should throw the expected error but the error is neglected due to empty deque and the test is passed. > > JBS issue : [8303948](https://bugs.openjdk.org/browse/JDK-8303948) This pull request has now been integrated. Changeset: a72ba383 Author: Varada M Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/a72ba3834781ef174e206aaf1d34dbb2ed305df1 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8303948: HsErrFileUtils.checkHsErrFileContent() fails to check the last pattern. Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/12970 From kim.barrett at oracle.com Tue Mar 21 07:07:58 2023 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Mar 2023 07:07:58 +0000 Subject: Atomic In-Reply-To: <01c94a6c-f1d1-56ba-920b-13fdad986b36@oracle.com> References: <01c94a6c-f1d1-56ba-920b-13fdad986b36@oracle.com> Message-ID: <9FFA04DA-732D-40F7-BFEF-AA31D02A786D@oracle.com> > On Mar 20, 2023, at 9:23 PM, David Holmes wrote: > > On 21/03/2023 1:42 am, Justin King wrote: >> While messing around with seeing if ThreadSanitizer would be useful in Hotspot, I rewrote runtime/atomic.hpp using compiler intrinsics (__atomic_* on GCC/Clang/XLC, interlocked for MSVC) instead of inline assembly. > > I assume you mean the platform specific atomic*.hpp files? > > Inline assembly doesn't get instrumented very well and the >> compiler cannot optimize it very well. Is there any want for replacing the inline assembly with compiler intrinsics, regardless of ThreadSanitizer? They also have intrinsics that can be used to build optimized implementations of parallel bit set manipulation as well. > > Sorry but this just seems like churn to me. First we have to go through the process of establishing the equivalence of the compiler intrinsics with the assembly code. Then make all the changes. Then deal with the potential that some os_cpu code might be compiled by multiple compilers. Then we have to deal with the possibility that the compilers might change behaviour or introduce bugs across releases (yeah these low-level things _should_ be stable but ...). > > What would we gain by doing any of this? I pretty much agree with David on this. > IMO the ideal place we would like to get to is use of C++ atomic operations, but I wouldn't want to go there via use of compiler intrinsics. And I don't know what challenges we would face trying to use C++ atomic ops. We?ve discussed and explicitly rejected the use of facilities in shared code. See the HotSpot Style Guide. Some platforms might use some of them (or corresponding built-ins) to implement some of Atomic. That?s a decision for the developers and maintainers of the various ports. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jsjolen at openjdk.org Tue Mar 21 09:55:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 21 Mar 2023 09:55:01 GMT Subject: Withdrawn: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12832 From jsjolen at openjdk.org Tue Mar 21 09:55:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 21 Mar 2023 09:55:00 GMT Subject: RFR: 8255414: Ensure OS functions always report to NMT In-Reply-To: References: Message-ID: <_Sea_NZte5aIwNLJORH_y0fsvIrMGBX828bUy1NRzEo=.83a7bd3e-3e80-41a4-ad3a-b21b07b611a2@github.com> On Thu, 2 Mar 2023 14:05:14 GMT, Johan Sj?len wrote: > Hi, > > This PR attempts to enforce the convention that: > > 1. Public `os` functions report to NMT > 2. `pd_` prefixed functions do not report to NMT > 3. Public `os` functions call into `pd_`-prefixed functions to do the actual work. > > This is a convention that has been only partially enforced, leading to some difficulties. For example, it's easy for double-accounting to NMT can occur if it's not clear what the `pd_`-prefixed functions do and do not do. Hi! We've had no more opinions on this, so I'm closing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12832#issuecomment-1477543438 From adinn at openjdk.org Tue Mar 21 11:28:49 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 21 Mar 2023 11:28:49 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: On Mon, 20 Mar 2023 15:07:13 GMT, Frederic Parain wrote: > Regarding the motivation of this CR: I filled this RFE because I found the code confusing. When null_check() is called with an offset argument being klass_offset_in_bytes() and length_offset_in_bytes(), it never emits an explicit null check. And using this method, or methods calling it might give a false sense of security. I doubt very much that there is a problem here. However, if there is one I believe it is to do with an unwary programmer not understanding how the implementation of calls with `_check_null` suffix work not whether they do what it says on the tin. The example cited here serves as a good vehicle to explain how that meainging is supported and show why it should give a perfectly solid sense of security. This is all about what happens when the emitted code accesses address 0 i.e. the internal representation of null. When loading a `klass` from an oop that is null we can rely on a SIGSEGV handler to catch the error, because the first page of memory is RW protected. The `klass` offset is a small positive number well below the page size. That means we don't need a null check -- an access via null is guaranteed to land in that first page and we can defer handling of that access to the SIGSEGV handler. As Roman indicated, the next step when we do enter the signal handler involves a lookup to see whether the PC at which the SEGV occurred is a legitimate one for a null dereference to occur. The compiler emits a list of such addresses for any given compiled method. If it is legitimate the handler ensures a NPE is delivered. If not it initiates a VM exit. Clearly, we must plant an explicit null check for any access where we might offset beyond the first page of memory (offset >= page size). We may also end up accessing access a page that is not RW protected if the offset is negative -- well, arguably, any such page will also be in the unmapped address range for all supported OSes but we still allow for the possibility. So, the `_null_check` variants do exactly what they say. They plant null checks where the SIGSEGV handler will not catch the error and only in those cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1477669181 From fparain at openjdk.org Tue Mar 21 11:59:48 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 21 Mar 2023 11:59:48 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: References: Message-ID: <1PWid2fmAMpOfkynHAIaeRJgSaGHGRR78fPDsedTRt8=.60d1994b-1caa-4ffc-9ead-706e3c0647e5@github.com> On Thu, 16 Mar 2023 20:02:56 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > load_klass now emits null check and other platforms supported The nulll_check() method is perfectly fine, and complements the work done in the signal handler for segmentation fault in the first page. But my point was not about the method itself, it was about cases where this method is used when it is provable that there's no need to insert an explicit null check because the signal handler is able to handle the case. It happens when the offset is statically known at VM compilation time, and this offset is smaller than a page size: the klass pointer offset and the array's length. But if you consider that the code is safer as written in its current form, I'll close the bug as not-an-issue. Anyway, it doesn't change the code being generated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1477708955 From coleenp at openjdk.org Tue Mar 21 13:21:51 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Mar 2023 13:21:51 GMT Subject: RFR: 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found In-Reply-To: References: Message-ID: On Tue, 21 Mar 2023 00:28:51 GMT, Coleen Phillimore wrote: > Removed the test. This test was missing a @compile and can't test what it is trying to test (just gets an OOM). See CR for more details. Thanks David and Dan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13110#issuecomment-1477823306 From coleenp at openjdk.org Tue Mar 21 13:21:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 21 Mar 2023 13:21:53 GMT Subject: Integrated: 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found In-Reply-To: References: Message-ID: On Tue, 21 Mar 2023 00:28:51 GMT, Coleen Phillimore wrote: > Removed the test. This test was missing a @compile and can't test what it is trying to test (just gets an OOM). See CR for more details. This pull request has now been integrated. Changeset: bbde2158 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/bbde2158d1d11be909292d0c8625211e6cf5359e Stats: 336 lines in 2 files changed: 0 ins; 336 del; 0 mod 8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found Reviewed-by: dholmes, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/13110 From stuefe at openjdk.org Tue Mar 21 14:24:43 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Mar 2023 14:24:43 GMT Subject: RFR: JDK-8304421: Introduce malloc size feedback [v7] In-Reply-To: References: <272GFUIwFKaILKNFZlpjTfD6W5PmiF2L2VIhQ0xhCnU=.68b71b8c-313d-47a6-9bde-162aee3572d1@github.com> Message-ID: <4Tgt8aTLUBpaBOwxXEz0RifCyQ1wKw0UoM_87CFwjJc=.4ca8b417-022f-47c6-bd70-51fc22a22f42@github.com> On Mon, 20 Mar 2023 17:23:03 GMT, Justin King wrote: > > Your proposal has costs: > > > > * the inherent risk of writing over malloc-allocated boundaries ("Any implementation returning an invalid size from malloc_usable_size is a broken implementation and has no business existing or being supported" sounds good and all but customers with crashing systems won't care if it's us screwing up or the libc maintainers). > > But that is the case for all of libc. `malloc_usable_size` is no different. > > > * The loss of precision of NMT-provided overwrite checks > > I fail to see how this is the case. The idea here is allocate at least N, then have `malloc` tell how much it actually gave `M`. M is the actual size of the allocation and what you want. This wouldn't be used except for arena-like implementations or maybe containers where extra size can be used, not fixed size C++ objects. Okay, I see what you did there. The trailing canary is now placed either after the excess size or the user requested size depending on whether the output parameter "allocated_size" was given or not. Still, not a big fan. Tying a difference in mechanics to whether or not an output receptor var had been given is at least surprising. > > > * increased complexity and reviewer churn. There is a ton of things to do and little reviewer time to go around. > > Sure, but adding simple size feedback and completely rewriting Arena to use Metaspace allocator are two different things, with the latter being much more complicated. Arena coding is decades old (to my knowledge) and, as you have probably noticed, not that awesome. It is also full of pitfalls. I have spent time reworking it, and it needs a lot of care to not break anything in hotspot. My foot is full of holes already. So it also needs a lot of thorough reviewers. Thankfully we managed to reduce the complexity of Arenas already by ripping out UseMallocOnly mode. Time spend reviewing this code could be spent improving e.g. Metaspace, and we'd arrive ultimately at a better solution and have less code to maintain. > > > Do the benefits outweigh these costs? Maybe, but we don't know that since there are no numbers. What we do know is that most small-grained allocations - that could benefit from your change most - are C++ objects with fixed sizes. Leaves those little raw buffers in things like stringStream, and arena chunks. > > C++ objects with fixed sizes are not the target here. Only allocations which can make use of the extra space, like arenas or contiguous containers. Which is why I had been asking for numbers. How much memory is actually to be gained by this change? After many years of supporting the JDK on the weirdest platforms I am very hesitant to overwrite malloc boundaries on the promise that this would be just fine. It is a risk, despite all you write, and it must be worth it. A few KB? Not worth it. A few dozen MB? That would be more interesting. > > > But for arena chunks in particular, it makes sense to discuss alternatives. E.g. we could just re-use the metaspace allocator for hs arenas. Metaspace is a much better arena allocator than hs arenas, which makes sense since Metaspace is the spiritual successor. > > A variant of that would be to just roll our own allocator for arenas. Allocate chunks via os::reseve/commit_memory, and take care of committing/uncommitting ourselves. That would be trivial to implement. > > Both examples would solve not only the overhead-per-chunk problem but also the retention problem in glibc and other libc implementations (e.g. AIX, Solaris), which I see as the larger problem. > > Doesn't the metaspace allocator have extra logic for garbage collection and limits on the maximum size of an allocation? Its unlikely to out perform a simple arena allocator which allocates chunks of memory and simply increments a pointer in most cases to dole out memory. Additionally all allocations in the arena are extremely short lived typically. Those that are not are very small, such as the arena used for JNI handles. Metaspace is an arena allocator. It is geared toward very fast allocation of tiny things and fast bulk release. In contrast to Hotspot Arenas it mmaps its chunks, has an effective free chunk management, and returns memory to the OS much more willingly than libc does. It also can deal with premature deallocation. The ties to GC are slim and could be factored out. I need to do this for Lilliput anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13081#issuecomment-1477929034 From jsjolen at openjdk.org Tue Mar 21 15:54:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 21 Mar 2023 15:54:00 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: <1V0Aeo7ZFaLastGrqrjLwuACsWZgfguO0OAQYPhLLPw=.f2cf160f-c7c6-44d6-b83e-f9ade6be0142@github.com> On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. I'm reverting this into a draft with the hope that I can replace this with something fast that checks the reqs outlined by Thomas. Edit: Closing it instead, it doesn't make sense to re-open this particular PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13088#issuecomment-1478084983 From jsjolen at openjdk.org Tue Mar 21 15:54:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 21 Mar 2023 15:54:01 GMT Subject: Withdrawn: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13088 From stuefe at openjdk.org Tue Mar 21 16:14:47 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Mar 2023 16:14:47 GMT Subject: RFR: 8304442: Defer VirtualMemoryTracker work until reporting In-Reply-To: References: Message-ID: On Sat, 18 Mar 2023 14:50:48 GMT, Johan Sj?len wrote: > Hi, > > The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead. > > In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed. > > I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code: > > > public class Test { > public static void main(String[] args) { > } > } > > > These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. The tests were only run once. > > > java -XX:NativeMemoryTracking=detail Test.java > > os::commit_memory > old | new | old / new > 935238 | 578979 | 1.6 > os::reserve_memory > old | new | new / old > 53628 | 21825 | 2.4 > > java -XX:NativeMemoryTracking=summary Test.java > > os::commit_memory > old | new | old/new > 1033701 | 59974 | 17.2 > > os::reserve_memory > old | new | old/new > 10067 | 2016 | 5 > > > > In summary mode we get the largest performance gains as `NativeCallStack` is missing. > > There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur. > Hi Thomas, thanks for the in-depth review! > > Alright, if it's a hard requirement that _reporting_ must be fast and not allocate memory, then this particular solution is a deal breaker. > > Regarding your ideas: > > 1. `commit_memory` is often called by metaspace, but `pd_create_stackguard_pages` is a close 2nd. > > 2. I actually think that we can get most of the gains from this PR by just allocating the linked list in an arena instead (`FixedItemArray` :)?). A large amount of the runtime is spent on doing these `NativeCallStack`s during node allocation in detailed mode, and malloc:ing is potentially (I'd measure it) costly in summary mode. Makes sense. I need to get that PR done, but I'm busy with Lilliput atm. I also dimly remember looking at NativeCallStack and finding that it was copied around too much. I mean, once its created its immutable, so one could just pass references or pointers around instead, or keep them with ref counting or similar. Not sure though if this still applies to the current NMT, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13088#issuecomment-1478139400 From jcking at google.com Tue Mar 21 17:34:08 2023 From: jcking at google.com (Justin King) Date: Tue, 21 Mar 2023 10:34:08 -0700 Subject: Atomic In-Reply-To: <9FFA04DA-732D-40F7-BFEF-AA31D02A786D@oracle.com> References: <01c94a6c-f1d1-56ba-920b-13fdad986b36@oracle.com> <9FFA04DA-732D-40F7-BFEF-AA31D02A786D@oracle.com> Message-ID: Fair, that is why I asked. It's cleaner and more portable than handwriting inline assembly on each platform but it's potentially risky. I'll leave it around for my ThreadSanitizer experiment only. Thanks! On Tue, Mar 21, 2023 at 12:08?AM Kim Barrett wrote: > > > > On Mar 20, 2023, at 9:23 PM, David Holmes > wrote: > > > > On 21/03/2023 1:42 am, Justin King wrote: > >> While messing around with seeing if ThreadSanitizer would be useful in > Hotspot, I rewrote runtime/atomic.hpp using compiler intrinsics (__atomic_* > on GCC/Clang/XLC, interlocked for MSVC) instead of inline assembly. > > > > I assume you mean the platform specific atomic*.hpp files? > > > > Inline assembly doesn't get instrumented very well and the > >> compiler cannot optimize it very well. Is there any want for replacing > the inline assembly with compiler intrinsics, regardless of > ThreadSanitizer? They also have intrinsics that can be used to build > optimized implementations of parallel bit set manipulation as well. > > > > Sorry but this just seems like churn to me. First we have to go through > the process of establishing the equivalence of the compiler intrinsics with > the assembly code. Then make all the changes. Then deal with the potential > that some os_cpu code might be compiled by multiple compilers. Then we have > to deal with the possibility that the compilers might change behaviour or > introduce bugs across releases (yeah these low-level things _should_ be > stable but ...). > > > > What would we gain by doing any of this? > > I pretty much agree with David on this. > > > IMO the ideal place we would like to get to is use of C++ atomic > operations, but I wouldn't want to go there via use of compiler intrinsics. > And I don't know what challenges we would face trying to use C++ atomic ops. > > We?ve discussed and explicitly rejected the use of facilities in > shared code. See the HotSpot Style Guide. > > Some platforms might use some of them (or corresponding built-ins) to > implement some of Atomic. That?s a > decision for the developers and maintainers of the various ports. > > > -- [image: Google Logo] Justin King Software Engineer jcking at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3999 bytes Desc: S/MIME Cryptographic Signature URL: From dholmes at openjdk.org Wed Mar 22 05:31:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 05:31:47 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive Message-ID: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). Each phase can be seen in distinct commits if you prefer to see the steps involved. Testing: - new ExitRace test - all dynamicArchive tests - tiers 1-4 Thanks. ------------- Commit messages: - Update test comments - Phase 4: remove unused methods and adjust dump_for_jcmd - Missed removing the check at the dump_at_exit callsite. - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. - Merge branch '8304147-test-only' into 8304147-dynamic-dump - Initial test - Phase 2: Move the dump to immediately after the prepare_for_dump - Phase 1: Relocate DynamicArchive::prepare_for_dump_at_exit to before_exit. - Add logging for dump prepation Changes: https://git.openjdk.org/jdk/pull/13134/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304147 Stats: 209 lines in 7 files changed: 156 ins; 41 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13134/head:pull/13134 PR: https://git.openjdk.org/jdk/pull/13134 From adinn at openjdk.org Wed Mar 22 13:38:44 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 22 Mar 2023 13:38:44 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: <1PWid2fmAMpOfkynHAIaeRJgSaGHGRR78fPDsedTRt8=.60d1994b-1caa-4ffc-9ead-706e3c0647e5@github.com> References: <1PWid2fmAMpOfkynHAIaeRJgSaGHGRR78fPDsedTRt8=.60d1994b-1caa-4ffc-9ead-706e3c0647e5@github.com> Message-ID: On Tue, 21 Mar 2023 11:57:04 GMT, Frederic Parain wrote: > But my point was not about the method itself, it was about cases where this method is used when it is provable that there's no need to insert an explicit null check because the signal handler is able to handle the case. Ah, ok, apologies for any confusion. I see your point. I have always understood that the presence of, for example, both `load_klass` and `load_klass_null_check` arises because they predate employment of the signal handler/read-protection for page 0. Without that protection it is necessary to do a `load_klass_null_check` on a path where an oop has not previously been null checked but a `load_klass` will suffice on a path where it is known to be non-null. I am not sure that is the actual history but I believe it does characterize the intended use of the two method variants. This distinction may be irrelevant given the current state of affairs but it would matter if for some reason we had to decommission the SEGV handler, for example if OpenJDK were ported to an OS which does not support read-protection for page 0. I don't suppose we are likely to encounter such a circumstance so it might be reasonable to collapse all calls to `load_klass_null_check` into plain calls to `load_klass`. That said, there is no good reason for this PR to modify `load_klass_null_check` to always perform a null check (i.e. the call to `null_check(Register)`). Arguably, the existing call to `null_check(Register, int)` could be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1479579651 From matsaave at openjdk.org Wed Mar 22 16:36:04 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Mar 2023 16:36:04 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables Message-ID: The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. ------------- Commit messages: - Made hashtable type - 8304069: ClassFileParser has ad-hoc hashtables Changes: https://git.openjdk.org/jdk/pull/13141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304069 Stats: 90 lines in 1 file changed: 6 ins; 43 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/13141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13141/head:pull/13141 PR: https://git.openjdk.org/jdk/pull/13141 From coleenp at openjdk.org Wed Mar 22 18:05:24 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Mar 2023 18:05:24 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 14:56:55 GMT, Matias Saavedra Silva wrote: > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. I have some suggestions for improving this. src/hotspot/share/classfile/classFileParser.cpp line 782: > 780: raw_hash += ((unsigned int)(uintptr_t)namesig->_sig) >> LogHeapWordSize; > 781: > 782: return (raw_hash + (unsigned int)(uintptr_t)namesig->_name) % HASH_ROW_SIZE; I don't know if you need to use % since that's what the hashtable will do to find the bucket. src/hotspot/share/classfile/classFileParser.cpp line 862: > 860: // Set containing interface names > 861: NameSigHashtable* interface_names = new NameSigHashtable(); > 862: bool dup = true; Can you change the variable name 'dup' to 'created'? src/hotspot/share/classfile/classFileParser.cpp line 868: > 866: for (index = 0; (index < itfs_len) && dup; index++) { > 867: const InstanceKlass* const k = _local_interfaces->at(index); > 868: interface_name = new NameSigHash(); You could use a local NameSigHash and copy for the values like: name_sig_hash = NameSigHash(k->name(), nullptr); Then the hashtable key could be a non-pointer, saving a pointer per entry and may be more efficient. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1353171894 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1145201747 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1145214822 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1145217695 From coleenp at openjdk.org Wed Mar 22 18:05:26 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Mar 2023 18:05:26 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 17:46:29 GMT, Coleen Phillimore wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > src/hotspot/share/classfile/classFileParser.cpp line 782: > >> 780: raw_hash += ((unsigned int)(uintptr_t)namesig->_sig) >> LogHeapWordSize; >> 781: >> 782: return (raw_hash + (unsigned int)(uintptr_t)namesig->_name) % HASH_ROW_SIZE; > > I don't know if you need to use % since that's what the hashtable will do to find the bucket. You could also make the hash function be name->identity_hash() (ignoring the nullptr for sig). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1145213379 From coleenp at openjdk.org Wed Mar 22 18:05:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Mar 2023 18:05:27 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 17:56:55 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 782: >> >>> 780: raw_hash += ((unsigned int)(uintptr_t)namesig->_sig) >> LogHeapWordSize; >>> 781: >>> 782: return (raw_hash + (unsigned int)(uintptr_t)namesig->_name) % HASH_ROW_SIZE; >> >> I don't know if you need to use % since that's what the hashtable will do to find the bucket. > > You could also make the hash function be name->identity_hash() (ignoring the nullptr for sig). Lastly, I think you need a constructor to null out the _sig field for the place where that's null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1145214126 From matsaave at openjdk.org Wed Mar 22 19:52:21 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Mar 2023 19:52:21 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v2] In-Reply-To: References: Message-ID: > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Coleen comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13141/files - new: https://git.openjdk.org/jdk/pull/13141/files/3b19b76a..17f7d8f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=00-01 Stats: 57 lines in 1 file changed: 5 ins; 20 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/13141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13141/head:pull/13141 PR: https://git.openjdk.org/jdk/pull/13141 From matsaave at openjdk.org Wed Mar 22 21:29:13 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Mar 2023 21:29:13 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v3] In-Reply-To: References: Message-ID: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Removed load_klass_null_check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/391af540..9a465166 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=01-02 Stats: 53 lines in 22 files changed: 0 ins; 30 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From matsaave at openjdk.org Wed Mar 22 21:31:43 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 22 Mar 2023 21:31:43 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v2] In-Reply-To: <1PWid2fmAMpOfkynHAIaeRJgSaGHGRR78fPDsedTRt8=.60d1994b-1caa-4ffc-9ead-706e3c0647e5@github.com> References: <1PWid2fmAMpOfkynHAIaeRJgSaGHGRR78fPDsedTRt8=.60d1994b-1caa-4ffc-9ead-706e3c0647e5@github.com> Message-ID: On Tue, 21 Mar 2023 11:57:04 GMT, Frederic Parain wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> load_klass now emits null check and other platforms supported > > The nulll_check() method is perfectly fine, and complements the work done in the signal handler for segmentation fault in the first page. But my point was not about the method itself, it was about cases where this method is used when it is provable that there's no need to insert an explicit null check because the signal handler is able to handle the case. It happens when the offset is statically known at VM compilation time, and this offset is smaller than a page size: the klass pointer offset and the array's length. > But if you consider that the code is safer as written in its current form, I'll close the bug as not-an-issue. Anyway, it doesn't change the code being generated. Thank you all for the insightful comments! The most recent commit removed load_klass_null_check entirely for all platforms except PPC which has unique behavior. This should be consistent with the prior behavior of this code and, as @fparain stated, is simply cleanup. If there is any further disagreement on what should be done in this PR, I can revert it to a draft until we have come to a consensus. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1480285307 From ccheung at openjdk.org Wed Mar 22 21:35:44 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 22 Mar 2023 21:35:44 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> On Wed, 22 Mar 2023 05:03:50 GMT, David Holmes wrote: > `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). > > Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). > > Each phase can be seen in distinct commits if you prefer to see the steps involved. > > Testing: > - new ExitRace test > - all dynamicArchive tests > - tiers 1-4 > > Thanks. Thanks for fixing this. I've couple of comments. src/hotspot/share/runtime/javaThread.cpp line 2031: > 2029: if (this->has_pending_exception()) { > 2030: this->clear_pending_exception(); > 2031: } I think the HandleMark can be removed. We may need to move lines 2026 - 2031 to the new `dump_at_exit` function. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ExitRaceTest.java line 52: > 50: dump(topArchiveName, > 51: "-Xlog:cds+dynamic=debug", > 52: "-XX:-CreateCoredumpOnCrash", Why disabling core dump? ------------- PR Review: https://git.openjdk.org/jdk/pull/13134#pullrequestreview-1353508181 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145430599 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145430945 From coleenp at openjdk.org Wed Mar 22 21:34:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Mar 2023 21:34:42 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v2] In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 19:52:21 GMT, Matias Saavedra Silva wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen comments This looks great. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1353507434 From dholmes at openjdk.org Wed Mar 22 21:54:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 21:54:42 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: On Wed, 22 Mar 2023 21:32:44 GMT, Calvin Cheung wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ExitRaceTest.java line 52: > >> 50: dump(topArchiveName, >> 51: "-Xlog:cds+dynamic=debug", >> 52: "-XX:-CreateCoredumpOnCrash", > > Why disabling core dump? Left over from developing the test on an unfixed VM. I will remove it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145446129 From dholmes at openjdk.org Wed Mar 22 22:02:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 22:02:44 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: On Wed, 22 Mar 2023 21:32:15 GMT, Calvin Cheung wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > src/hotspot/share/runtime/javaThread.cpp line 2031: > >> 2029: if (this->has_pending_exception()) { >> 2030: this->clear_pending_exception(); >> 2031: } > > I think the HandleMark can be removed. > We may need to move lines 2026 - 2031 to the new `dump_at_exit` function. Thanks missed that. Not sure how we can get here with a pending exception though: DestroyJavaVM() -> Threads::destroy_vm(); -> wait till last non-daemon thread -> commit shutdown event -> JavaThread::invoke_shutdown_hooks() There is nowhere for an exception to materialize in this path AFAICS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145449729 From dholmes at openjdk.org Wed Mar 22 22:02:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 22:02:44 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: On Wed, 22 Mar 2023 21:56:40 GMT, David Holmes wrote: >> src/hotspot/share/runtime/javaThread.cpp line 2031: >> >>> 2029: if (this->has_pending_exception()) { >>> 2030: this->clear_pending_exception(); >>> 2031: } >> >> I think the HandleMark can be removed. >> We may need to move lines 2026 - 2031 to the new `dump_at_exit` function. > > Thanks missed that. Not sure how we can get here with a pending exception though: > > DestroyJavaVM() > -> Threads::destroy_vm(); > -> wait till last non-daemon thread > -> commit shutdown event > -> JavaThread::invoke_shutdown_hooks() > > There is nowhere for an exception to materialize in this path AFAICS. Also note no need to move this as the code below clears any pending exception (from running the hooks). If we could get here with an exception pending it would have broken running of the hooks before we even had dynamic archiving. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145451729 From dholmes at openjdk.org Wed Mar 22 22:10:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 22:10:41 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: On Wed, 22 Mar 2023 21:59:36 GMT, David Holmes wrote: >> Thanks missed that. Not sure how we can get here with a pending exception though: >> >> DestroyJavaVM() >> -> Threads::destroy_vm(); >> -> wait till last non-daemon thread >> -> commit shutdown event >> -> JavaThread::invoke_shutdown_hooks() >> >> There is nowhere for an exception to materialize in this path AFAICS. > > Also note no need to move this as the code below clears any pending exception (from running the hooks). If we could get here with an exception pending it would have broken running of the hooks before we even had dynamic archiving. But looking at the code history we did always clear the exception before running the hooks. So I will restore this parts as it was before JDK-8266770. That means the HandleMark stays too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145457696 From dholmes at openjdk.org Wed Mar 22 22:17:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 22:17:27 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: > `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). > > Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). > > Each phase can be seen in distinct commits if you prefer to see the steps involved. > > Testing: > - new ExitRace test > - all dynamicArchive tests > - tiers 1-4 > > Thanks. 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 12 additional commits since the last revision: - Restore comment to as it was pre JDK-8266770 - Update test to removing debugging code - Merge branch 'master' into 8304147-dynamic-dump - Update test comments - Phase 4: remove unused methods and adjust dump_for_jcmd - Missed removing the check at the dump_at_exit callsite. - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. Minor tweak to test. - Merge branch '8304147-test-only' into 8304147-dynamic-dump - Initial test - Phase 2: Move the dump to immediately after the prepare_for_dump - ... and 2 more: https://git.openjdk.org/jdk/compare/d0948571...518f5409 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13134/files - new: https://git.openjdk.org/jdk/pull/13134/files/d0d0d5d1..518f5409 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13134&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13134&range=00-01 Stats: 3194 lines in 227 files changed: 1758 ins; 951 del; 485 mod Patch: https://git.openjdk.org/jdk/pull/13134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13134/head:pull/13134 PR: https://git.openjdk.org/jdk/pull/13134 From dholmes at openjdk.org Wed Mar 22 22:17:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Mar 2023 22:17:28 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: On Wed, 22 Mar 2023 21:33:16 GMT, Calvin Cheung 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/d0948571...518f5409 > > Thanks for fixing this. I've couple of comments. Thanks for looking at this @calvinccheung ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13134#issuecomment-1480326316 From ccheung at openjdk.org Wed Mar 22 22:26:42 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 22 Mar 2023 22:26:42 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <9YWhlMTzLNSffBzM6965OHZz1Tj1oqnNei3rIfotB-Y=.4e1e396b-f18d-49b4-a6a0-1267637f57e0@github.com> Message-ID: <1N0MEjgpfnhrEhlxikIY7yKi4emCLyh_XVePg3GJxQs=.3b01b87c-5bd7-470a-b04e-eafb3ee7a684@github.com> On Wed, 22 Mar 2023 22:07:54 GMT, David Holmes wrote: >> Also note no need to move this as the code below clears any pending exception (from running the hooks). If we could get here with an exception pending it would have broken running of the hooks before we even had dynamic archiving. > > But looking at the code history we did always clear the exception before running the hooks. So I will restore this parts as it was before JDK-8266770. That means the HandleMark stays too. Thanks for the explanations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1145468535 From ccheung at openjdk.org Wed Mar 22 22:29:46 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 22 Mar 2023 22:29:46 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Wed, 22 Mar 2023 22:17:27 GMT, David Holmes wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > 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 12 additional commits since the last revision: > > - Restore comment to as it was pre JDK-8266770 > - Update test to removing debugging code > - Merge branch 'master' into 8304147-dynamic-dump > - Update test comments > - Phase 4: remove unused methods and adjust dump_for_jcmd > - Missed removing the check at the dump_at_exit callsite. > - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. > Minor tweak to test. > - Merge branch '8304147-test-only' into 8304147-dynamic-dump > - Initial test > - Phase 2: Move the dump to immediately after the prepare_for_dump > - ... and 2 more: https://git.openjdk.org/jdk/compare/25eca24d...518f5409 Updates look good. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13134#pullrequestreview-1353561431 From tsteele at openjdk.org Wed Mar 22 23:19:47 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Wed, 22 Mar 2023 23:19:47 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 10:17:57 GMT, Deepa Kumari wrote: >> It was failing as It was using the C++ demangling interface (Demangle) of the old demangler (that is, the C++ API as opposed to the C one). It is not supported by xlclang++ on AIX. >> To demangle names generated by xlclang++ , use cxxabi.h __cxa_demangle interface ( see cxxabi.h). >> >> This Solution applies to the following test >> >> 1. SecondaryErrorTest.java` >> 2. TestSigInfoInHsErrFile.java >> >> >> Reported Issue : [JDK - 8303082](https://bugs.openjdk.org/browse/JDK-8303082) > > Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8303082 : [AIX] Missing C++ name demangling with XLClang++ LGTM ------------- Marked as reviewed by tsteele (Committer). PR Review: https://git.openjdk.org/jdk/pull/12742#pullrequestreview-1353619105 From dholmes at openjdk.org Thu Mar 23 01:21:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Mar 2023 01:21:33 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v3] In-Reply-To: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> References: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> Message-ID: On Wed, 22 Mar 2023 21:29:13 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed load_klass_null_check So to re-state: > So basically this change is statically deciding that needs_explicit_null_check will always be false at these call-sites. In which case is there any kind of static assertion we can use to verify that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1480451218 From duke at openjdk.org Thu Mar 23 05:32:42 2023 From: duke at openjdk.org (Deepa Kumari) Date: Thu, 23 Mar 2023 05:32:42 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 23:17:03 GMT, Tyler Steele wrote: > LGTM Thanks @backwaterred . ------------- PR Comment: https://git.openjdk.org/jdk/pull/12742#issuecomment-1480625589 From dholmes at openjdk.org Thu Mar 23 06:31:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Mar 2023 06:31:41 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v2] In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 19:52:21 GMT, Matias Saavedra Silva wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Coleen comments This conversion looks good but I was confused by the way the original code was doing things. Once we have this conversion I think we could clean things up further: 1. Interfaces don't need `NameSigHash`, all we need is a map of names, so we should be able to directly have a RHT of `Symbol*` for the `interface_name_table`. 2. `NameSigHash` is the wrong terminology - we are checking names and descriptors [JVMS 4.3], not names and signatures [JVMS4.7.9.1]! (And a Java Language "signature" is something different again [JLS 8.4.2]! Unfortunately I think we misuse "signature" throughout the VM, so maybe fixing it here will serve little purpose. ------------- PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1353927021 From fparain at openjdk.org Thu Mar 23 13:38:24 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 23 Mar 2023 13:38:24 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v3] In-Reply-To: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> References: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> Message-ID: On Wed, 22 Mar 2023 21:29:13 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed load_klass_null_check An assertion would look like this: assert(oopDesc::klass_offset_in_bytes() < static_cast(os::vm_page_size(), "Otherwise, an explicit null check is required"); ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1481206931 From coleenp at openjdk.org Thu Mar 23 14:21:19 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Mar 2023 14:21:19 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v3] In-Reply-To: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> References: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> Message-ID: On Wed, 22 Mar 2023 21:29:13 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed load_klass_null_check This seems to clear up the confusion around this null_check call. Maybe add two asserts in shared oops code that klass_offset_in_bytes() and array_lengh_offset_in_bytes() are < pagesize would be sufficient to make this bug proof, but honestly seems 100% unlikely enough to not to bother. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1354741670 From jcking at openjdk.org Thu Mar 23 16:03:12 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 23 Mar 2023 16:03:12 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes Message-ID: Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. ------------- Commit messages: - Statically allocate ObjectSynchronizer mutexes Changes: https://git.openjdk.org/jdk/pull/13160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304820 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13160/head:pull/13160 PR: https://git.openjdk.org/jdk/pull/13160 From matsaave at openjdk.org Thu Mar 23 16:49:04 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 23 Mar 2023 16:49:04 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v3] In-Reply-To: References: Message-ID: > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Interface uses normal ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13141/files - new: https://git.openjdk.org/jdk/pull/13141/files/17f7d8f0..5492f5eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13141/head:pull/13141 PR: https://git.openjdk.org/jdk/pull/13141 From coleenp at openjdk.org Thu Mar 23 18:53:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Mar 2023 18:53:05 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v3] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 16:49:04 GMT, Matias Saavedra Silva wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Interface uses normal ResourceHashtable Every cleanup suggests more cleanups. src/hotspot/share/classfile/classFileParser.cpp line 866: > 864: // Set containing interface names > 865: ResourceHashtable* interface_names = new ResourceHashtable(); > 866: Symbol* interface_name; Minor point - you can declare Symbol* interface_name at line 869. src/hotspot/share/classfile/classFileParser.cpp line 1595: > 1593: // Set containing name-signature pairs > 1594: NameSigHashtable* names_and_sigs = new NameSigHashtable(); > 1595: NameSigHash name_and_sig; The same thing is true with this - you can remove the null constructor and just create the NameSigHash object in the for() scope, since it's not used outside the scope anymore. src/hotspot/share/classfile/classFileParser.cpp line 2835: > 2833: // Set containing name-signature pairs > 2834: NameSigHashtable* names_and_sigs = new NameSigHashtable(); > 2835: NameSigHash name_and_sig; also can be moved inside for() scope. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1355347788 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1146678589 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1146679818 PR Review Comment: https://git.openjdk.org/jdk/pull/13141#discussion_r1146680176 From matsaave at openjdk.org Thu Mar 23 19:39:50 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 23 Mar 2023 19:39:50 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v4] In-Reply-To: References: Message-ID: <3wB1oip7dGQ91qLYdM7bORQe3PaU9QjfCJcs9lFfAUk=.f6f84407-2a80-4285-a690-5a0255ec5ff6@github.com> > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Moved declarations into for loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13141/files - new: https://git.openjdk.org/jdk/pull/13141/files/5492f5eb..20a2006a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13141/head:pull/13141 PR: https://git.openjdk.org/jdk/pull/13141 From coleenp at openjdk.org Thu Mar 23 20:56:25 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Mar 2023 20:56:25 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception Message-ID: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). ------------- Commit messages: - 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception Changes: https://git.openjdk.org/jdk/pull/13169/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297977 Stats: 3900 lines in 14 files changed: 102 ins; 3798 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13169/head:pull/13169 PR: https://git.openjdk.org/jdk/pull/13169 From dcubed at openjdk.org Thu Mar 23 21:04:21 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 23 Mar 2023 21:04:21 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 15:53:28 GMT, Justin King wrote: > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. Marked as reviewed by dcubed (Reviewer). Thumbs up. src/hotspot/share/runtime/synchronizer.cpp line 743: > 741: // Index into the lock array based on the current object address. > 742: static_assert(is_power_of_2(ARRAY_SIZE(gInflationLocks)), "must be"); > 743: size_t ix = (cast_from_oop(obj) >> 5) & (ARRAY_SIZE(gInflationLocks)-1); Since you are touching the line: nit: s/-1/ - 1/ ------------- PR Review: https://git.openjdk.org/jdk/pull/13160#pullrequestreview-1355612280 PR Comment: https://git.openjdk.org/jdk/pull/13160#issuecomment-1481902381 PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1146841808 From mseledtsov at openjdk.org Thu Mar 23 21:11:05 2023 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Thu, 23 Mar 2023 21:11:05 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception In-Reply-To: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: On Thu, 23 Mar 2023 20:49:08 GMT, Coleen Phillimore wrote: > These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. > Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. > > I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). Looks good to me. Thank you Coleen. ------------- Marked as reviewed by mseledtsov (Committer). PR Review: https://git.openjdk.org/jdk/pull/13169#pullrequestreview-1355643759 From lmesnik at openjdk.org Thu Mar 23 21:20:16 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 23 Mar 2023 21:20:16 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception In-Reply-To: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: On Thu, 23 Mar 2023 20:49:08 GMT, Coleen Phillimore wrote: > These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. > Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. > > I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13169#pullrequestreview-1355659627 From matsaave at openjdk.org Thu Mar 23 21:28:17 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 23 Mar 2023 21:28:17 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v5] In-Reply-To: References: Message-ID: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Removed default constructor and changed declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13141/files - new: https://git.openjdk.org/jdk/pull/13141/files/20a2006a..2c89b165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13141&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13141/head:pull/13141 PR: https://git.openjdk.org/jdk/pull/13141 From lmesnik at openjdk.org Thu Mar 23 21:39:38 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 23 Mar 2023 21:39:38 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception In-Reply-To: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: <_D-og9-RSCxMpPWjwlRakHy7P2ttnJrqjBCJvw3HLnE=.6565c92e-f4dd-4186-ae17-df9ba1147fef@github.com> On Thu, 23 Mar 2023 20:49:08 GMT, Coleen Phillimore wrote: > These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. > Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. > > I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). There is an infra issue downloading jtreg, I don't know who supports GHA actions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13169#issuecomment-1481945616 From jcking at openjdk.org Thu Mar 23 21:48:49 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 23 Mar 2023 21:48:49 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v2] In-Reply-To: References: Message-ID: <2hvVr1cOb4OOUHovLEJ5kIkBA3gdDPJqP6ssLcX7Z_Y=.e3893876-3882-4e0e-8a12-09d2b643c1cd@github.com> > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update existing spacing since line is being touched anyway Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13160/files - new: https://git.openjdk.org/jdk/pull/13160/files/0ff0ebd0..d6afef79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13160/head:pull/13160 PR: https://git.openjdk.org/jdk/pull/13160 From jcking at openjdk.org Thu Mar 23 21:48:52 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 23 Mar 2023 21:48:52 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v2] In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 20:56:36 GMT, Daniel D. Daugherty wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Update existing spacing since line is being touched anyway >> >> Signed-off-by: Justin King > > src/hotspot/share/runtime/synchronizer.cpp line 743: > >> 741: // Index into the lock array based on the current object address. >> 742: static_assert(is_power_of_2(ARRAY_SIZE(gInflationLocks)), "must be"); >> 743: size_t ix = (cast_from_oop(obj) >> 5) & (ARRAY_SIZE(gInflationLocks)-1); > > Since you are touching the line: > nit: s/-1/ - 1/ Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1146901711 From coleenp at openjdk.org Thu Mar 23 21:49:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Mar 2023 21:49:50 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v5] In-Reply-To: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> References: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> Message-ID: On Thu, 23 Mar 2023 21:28:17 GMT, Matias Saavedra Silva wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed default constructor and changed declarations Looks good to me! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1355704985 From jcking at openjdk.org Thu Mar 23 21:50:45 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 23 Mar 2023 21:50:45 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 15:53:28 GMT, Justin King wrote: > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. Hm. We may want to try placing each mutex on separate cache lines if necessary. Can be done by creating a lightweight wrapper struct which uses `alignas(DEFAULT_CACHE_LINE_SIZE)`. Thoughts? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13160#issuecomment-1481957191 From coleenp at openjdk.org Thu Mar 23 21:53:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 23 Mar 2023 21:53:22 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception [v2] In-Reply-To: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: > These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. > Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. > > I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Tiny change to restart GHA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13169/files - new: https://git.openjdk.org/jdk/pull/13169/files/c21b3d01..b6c3be66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13169&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13169&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13169/head:pull/13169 PR: https://git.openjdk.org/jdk/pull/13169 From dholmes at openjdk.org Thu Mar 23 22:14:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Mar 2023 22:14:22 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v5] In-Reply-To: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> References: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> Message-ID: On Thu, 23 Mar 2023 21:28:17 GMT, Matias Saavedra Silva wrote: >> The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed default constructor and changed declarations Looks good! Thanks for the additional cleanups/simplifications. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13141#pullrequestreview-1355740191 From dholmes at openjdk.org Thu Mar 23 22:18:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Mar 2023 22:18:36 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v3] In-Reply-To: References: <8O0kA15xGwJerDgC7YGLBKzfK6_JY0LBz7fOBuw0ZQU=.6144b297-c4cf-4e85-a783-5c53c16649af@github.com> Message-ID: <_cv89z2-usBl8r0-0UahVgq5B10MVMtY_RdszBehr90=.3d42ff3c-fc13-4238-b06e-cc29b5521f85@github.com> On Thu, 23 Mar 2023 14:18:16 GMT, Coleen Phillimore wrote: > Maybe add two asserts in shared oops code that klass_offset_in_bytes() and array_lengh_offset_in_bytes() are < pagesize would be sufficient to make this bug proof, The asserts would make me happier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13026#issuecomment-1481985470 From dholmes at openjdk.org Fri Mar 24 05:03:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Mar 2023 05:03:30 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v2] In-Reply-To: <2hvVr1cOb4OOUHovLEJ5kIkBA3gdDPJqP6ssLcX7Z_Y=.e3893876-3882-4e0e-8a12-09d2b643c1cd@github.com> References: <2hvVr1cOb4OOUHovLEJ5kIkBA3gdDPJqP6ssLcX7Z_Y=.e3893876-3882-4e0e-8a12-09d2b643c1cd@github.com> Message-ID: On Thu, 23 Mar 2023 21:48:49 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update existing spacing since line is being touched anyway > > Signed-off-by: Justin King Seems fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13160#pullrequestreview-1356003088 From duke at openjdk.org Fri Mar 24 13:10:44 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 24 Mar 2023 13:10:44 GMT Subject: Withdrawn: 8300840: Update test runtime/Thread/StopAtExit.java to include Null Pointer Exception as one of the allowed exceptions In-Reply-To: References: Message-ID: <1D5XUhKdr5Z5VTooZR9S2Br5YbQa4vEoOVjM9Mt62KA=.c1e83e4d-22d1-4d66-8929-2cd8a7324e9e@github.com> On Tue, 14 Mar 2023 10:18:32 GMT, Afshin Zafari wrote: > In the test, NPE is caught with no action. > ### Test > mach5 tier1-5 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13013 From coleenp at openjdk.org Fri Mar 24 13:27:47 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Mar 2023 13:27:47 GMT Subject: RFR: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception [v2] In-Reply-To: References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: On Thu, 23 Mar 2023 21:53:22 GMT, Coleen Phillimore wrote: >> These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. >> Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. >> >> I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Tiny change to restart GHA Thanks Misha and Leonid. GHA seems to be happier now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13169#issuecomment-1482790526 From coleenp at openjdk.org Fri Mar 24 13:27:49 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Mar 2023 13:27:49 GMT Subject: Integrated: 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception In-Reply-To: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> References: <0G9Vc6VjFW5lwtvLEQ99bgQBfcc206xkJXYYFGSuuCo=.db97512a-6caa-43b8-b9b3-496d77629b80@github.com> Message-ID: On Thu, 23 Mar 2023 20:49:08 GMT, Coleen Phillimore wrote: > These vmTestbase/nsk/stress/except tests all allocate enough memory to get an OutOfMemoryError then try to throw an exception for a variety of error conditions. The tests pass (or all say it's "Skipped ...") if that throws OutOfMemoryError, which all the tests do. > Only except001.java did something useful - called a function that gets OOM reflectively then tests that it got an InvocationTargetException so I moved that to runtime/reflect/ReflectOutOfMemoryError.java. This change removes the rest. > > I couldn't reproduce the original failure in except012.java, which gets another exception (not OOM or ThreadDeath). This pull request has now been integrated. Changeset: 4ec720db Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/4ec720db9f1fedb5da96e70d1a8c5da5e773a5a7 Stats: 3900 lines in 14 files changed: 102 ins; 3798 del; 0 mod 8297977: vmTestbase/nsk/stress/except/except012.java fails with unexpected Exception Reviewed-by: mseledtsov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/13169 From matsaave at openjdk.org Fri Mar 24 15:11:43 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 24 Mar 2023 15:11:43 GMT Subject: RFR: 8304069: ClassFileParser has ad-hoc hashtables [v5] In-Reply-To: References: <-8CJ_UMmg1qiJREOCoixs80KqF0fVddnFn-12um6kLQ=.d17749a2-d796-4d19-ba23-e1588d674662@github.com> Message-ID: On Thu, 23 Mar 2023 21:46:49 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed default constructor and changed declarations > > Looks good to me! Thank you for the reviews @coleenp and @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13141#issuecomment-1482960236 From matsaave at openjdk.org Fri Mar 24 15:48:13 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 24 Mar 2023 15:48:13 GMT Subject: Integrated: 8304069: ClassFileParser has ad-hoc hashtables In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 14:56:55 GMT, Matias Saavedra Silva wrote: > The ClassFileParser has ad-hoc hash tables for checking for duplicate names for fields, methods and interfaces. ResourceHashtable will now be used instead. Verified with tier1-4 tests. This pull request has now been integrated. Changeset: d8ba227a Author: Matias Saavedra Silva Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/d8ba227aa4fcfdd2ab3df005dc3ef9b1e220d435 Stats: 106 lines in 1 file changed: 5 ins; 64 del; 37 mod 8304069: ClassFileParser has ad-hoc hashtables Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13141 From jcking at openjdk.org Fri Mar 24 16:22:50 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 16:22:50 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants Message-ID: Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. ------------- Commit messages: - Update spacing - Statically initialize parts of Bytecodes Changes: https://git.openjdk.org/jdk/pull/13179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304884 Stats: 591 lines in 2 files changed: 299 ins; 263 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13179/head:pull/13179 PR: https://git.openjdk.org/jdk/pull/13179 From kvn at openjdk.org Fri Mar 24 16:38:02 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 24 Mar 2023 16:38:02 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Add support for SR'ing some inputs of merges used for field loads Thank you, @JohnTortugo, for continue working on it. I will test it and do proper review late. Of cause @iwanowww have to approve it too :) ------------- PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357067077 From jcking at openjdk.org Fri Mar 24 16:41:50 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 16:41:50 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v10] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Update Visual Studio to be 17.1 Signed-off-by: Justin King - Merge remote-tracking branch 'upstream/master' into popcount - Move template declaration Signed-off-by: Justin King - Add default template implementation Signed-off-by: Justin King - Add missing #endif Signed-off-by: Justin King - Go back to templating for count_trailing_zeros for consistency Signed-off-by: Justin King - Remove intrinsic specifier for CountOneBits Signed-off-by: Justin King - Redo non-templated approach Signed-off-by: Justin King - Remove unnecessary templating from count_trailing_zeros Signed-off-by: Justin King - Fix ambiguous call Signed-off-by: Justin King - ... and 4 more: https://git.openjdk.org/jdk/compare/97649489...1bc46ffa ------------- Changes: https://git.openjdk.org/jdk/pull/13103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=09 Stats: 434 lines in 4 files changed: 203 ins; 151 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From kvn at openjdk.org Fri Mar 24 16:43:13 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 24 Mar 2023 16:43:13 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Add support for SR'ing some inputs of merges used for field loads You new test failed in GHA testing with 32-bit VM: `Could not find VM flag "UseCompressedOops" in @IR rule 1 at int`. You need to adjust next rule: `@IR(counts = { IRNode.ALLOC, "2" }, applyIf = { "UseCompressedOops", "false" })` ------------- PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1483098691 From jwaters at openjdk.org Fri Mar 24 17:20:39 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 24 Mar 2023 17:20:39 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants In-Reply-To: References: Message-ID: <01nD8Ivdg4OhHgJrc5JNNdPlrX4SOwh0u-1mlaKlHZ0=.33c64467-0bfa-462c-b9e0-06a772e8040a@github.com> On Fri, 24 Mar 2023 16:14:50 GMT, Justin King wrote: > Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. Not a review, but I want to point out that Bytecodes::_flags is declared as a jchar and defined as an unsigned short, might probably be helpful and less confusing to make it an unsigned short in both places. No comment on the other changes ------------- PR Comment: https://git.openjdk.org/jdk/pull/13179#issuecomment-1483152951 From matsaave at openjdk.org Fri Mar 24 17:45:34 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 24 Mar 2023 17:45:34 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Wed, 22 Mar 2023 22:17:27 GMT, David Holmes wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > 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 12 additional commits since the last revision: > > - Restore comment to as it was pre JDK-8266770 > - Update test to removing debugging code > - Merge branch 'master' into 8304147-dynamic-dump > - Update test comments > - Phase 4: remove unused methods and adjust dump_for_jcmd > - Missed removing the check at the dump_at_exit callsite. > - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. > Minor tweak to test. > - Merge branch '8304147-test-only' into 8304147-dynamic-dump > - Initial test > - Phase 2: Move the dump to immediately after the prepare_for_dump > - ... and 2 more: https://git.openjdk.org/jdk/compare/df50e744...518f5409 Consolidating some of the simpler methods is a good idea! LGTM ------------- Marked as reviewed by matsaave (Author). PR Review: https://git.openjdk.org/jdk/pull/13134#pullrequestreview-1357179295 From jcking at openjdk.org Fri Mar 24 17:59:15 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 17:59:15 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v2] In-Reply-To: References: Message-ID: > Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update definition to match declaration Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13179/files - new: https://git.openjdk.org/jdk/pull/13179/files/87cf87ff..d1a8dbd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13179/head:pull/13179 PR: https://git.openjdk.org/jdk/pull/13179 From jcking at openjdk.org Fri Mar 24 17:59:18 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 17:59:18 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants In-Reply-To: <01nD8Ivdg4OhHgJrc5JNNdPlrX4SOwh0u-1mlaKlHZ0=.33c64467-0bfa-462c-b9e0-06a772e8040a@github.com> References: <01nD8Ivdg4OhHgJrc5JNNdPlrX4SOwh0u-1mlaKlHZ0=.33c64467-0bfa-462c-b9e0-06a772e8040a@github.com> Message-ID: On Fri, 24 Mar 2023 17:17:53 GMT, Julian Waters wrote: > Not a review, but I want to point out that Bytecodes::_flags is declared as a jchar and defined as an unsigned short, might probably be helpful and less confusing to make it an unsigned short in both places. No comment on the other changes Switched to `jchar`in both places. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13179#issuecomment-1483197115 From coleenp at openjdk.org Fri Mar 24 18:43:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Mar 2023 18:43:08 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Wed, 22 Mar 2023 22:17:27 GMT, David Holmes wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > 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 12 additional commits since the last revision: > > - Restore comment to as it was pre JDK-8266770 > - Update test to removing debugging code > - Merge branch 'master' into 8304147-dynamic-dump > - Update test comments > - Phase 4: remove unused methods and adjust dump_for_jcmd > - Missed removing the check at the dump_at_exit callsite. > - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. > Minor tweak to test. > - Merge branch '8304147-test-only' into 8304147-dynamic-dump > - Initial test > - Phase 2: Move the dump to immediately after the prepare_for_dump > - ... and 2 more: https://git.openjdk.org/jdk/compare/a3c7e999...518f5409 This is a very nice simplification of the JVM exit paths. I had a few minor comments. src/hotspot/share/cds/dynamicArchive.cpp line 383: > 381: ExceptionMark em(current); > 382: ResourceMark rm(current); > 383: HandleMark hm(current); Why is there a HandleMark here? Should it be lower in the call stack? src/hotspot/share/cds/dynamicArchive.cpp line 385: > 383: HandleMark hm(current); > 384: > 385: if (!(DynamicDumpSharedSpaces && archive_name != nullptr)) { Can you make this !DynamicDumpSharedSpaces || archive_name == nullptr so it's easier to read. I'm trying to figure out how archive_name relates to ArchiveClassesAtExit and why you made the switch. src/hotspot/share/cds/dynamicArchive.cpp line 389: > 387: } > 388: > 389: log_info(cds,dynamic)("Preparing for dynamic dump at exit in thread %s", current->name()); nit, needs a ' ' between cds, dynamic. src/hotspot/share/cds/dynamicArchive.cpp line 391: > 389: log_info(cds,dynamic)("Preparing for dynamic dump at exit in thread %s", current->name()); > 390: > 391: MetaspaceShared::link_shared_classes(false/*not from jcmd*/, current); link_shared_classes is declared with TRAPS, so this should have a JavaThread* THREAD = current; and use HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION macros. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13134#pullrequestreview-1357247610 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1147940650 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1147939836 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1147940076 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1147937042 From matsaave at openjdk.org Fri Mar 24 18:47:43 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 24 Mar 2023 18:47:43 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v4] In-Reply-To: References: Message-ID: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Added asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/9a465166..e8b7f05d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=02-03 Stats: 28 lines in 13 files changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From jcking at openjdk.org Fri Mar 24 18:48:26 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 18:48:26 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v11] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update Visual Studio Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/1bc46ffa..167781b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From matsaave at openjdk.org Fri Mar 24 18:50:00 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 24 Mar 2023 18:50:00 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: References: Message-ID: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Removed accidental change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/e8b7f05d..c6d7947e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From coleenp at openjdk.org Fri Mar 24 18:53:32 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Mar 2023 18:53:32 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v2] In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 17:59:15 GMT, Justin King wrote: >> Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update definition to match declaration > > Signed-off-by: Justin King This seems reasonable. Some suggested changes. src/hotspot/share/interpreter/bytecodes.cpp line 32: > 30: #include "utilities/bytes.hpp" > 31: > 32: #define JVM_BYTECODES(XX) \ The convention for X macros in the code is usually naming the whole macro {JVM_}BYTECODES_DO and using a lower case argument. "def" would work and look more consistent than XX. src/hotspot/share/interpreter/bytecodes.cpp line 334: > 332: }; > 333: > 334: jchar Bytecodes::_flags[(1< References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> Message-ID: On Fri, 24 Mar 2023 18:50:00 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed accidental change Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1357270451 From kvn at openjdk.org Fri Mar 24 19:46:36 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 24 Mar 2023 19:46:36 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Add support for SR'ing some inputs of merges used for field loads Initial review. src/hotspot/share/code/debugInfo.hpp line 199: > 197: // ObjectValue describing an object that was scalar replaced. > 198: > 199: class ObjectMergeValue: public ScopeValue { Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts. src/hotspot/share/opto/callnode.cpp line 1479: > 1477: #ifdef ASSERT > 1478: _alloc(alloc), > 1479: #endif May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have. src/hotspot/share/opto/callnode.hpp line 511: > 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation > 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how > 511: // 'spobj' is used in both scenarios are described below. I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information. I think it should be separate Node which points to array of SFSO id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field. SFSO could be created before the merge. Consider: Point p = new Point(); Point q = foo(); if (cond) { q = p; } trap(p, q); src/hotspot/share/opto/callnode.hpp line 519: > 517: // _nfields : how many fields the SR object has. > 518: // _alloc : pointer to the Allocate object that previously created the SR object. > 519: // Only used for debug purposes. May be useful in other cases too in a future not only in debug. src/hotspot/share/opto/macro.hpp line 196: > 194: Node* size_in_bytes); > 195: > 196: static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc); Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one. ------------- PR Review: https://git.openjdk.org/jdk/pull/12897#pullrequestreview-1357285068 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147961058 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147963487 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147991641 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147965112 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1147973203 From fparain at openjdk.org Fri Mar 24 19:48:32 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 24 Mar 2023 19:48:32 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> Message-ID: On Fri, 24 Mar 2023 18:50:00 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed accidental change Marked as reviewed by fparain (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1357334393 From xliu at openjdk.org Fri Mar 24 19:56:32 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 24 Mar 2023 19:56:32 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Add support for SR'ing some inputs of merges used for field loads src/hotspot/share/opto/callnode.hpp line 614: > 612: int merge_pointer_idx(JVMState* jvms) const { > 613: assert(jvms != nullptr, "JVMS reference is null."); > 614: return jvms->scloff() + _merge_pointer_idx; how about we also assert is_from_merge() here? Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. here we use scloff-based. I think either is okay, but we need consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148000014 From jcking at openjdk.org Fri Mar 24 23:04:12 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 23:04:12 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v3] In-Reply-To: References: Message-ID: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> > Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Replace XX with def and add _DO suffix Signed-off-by: Justin King - Fix compiler warnings Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13179/files - new: https://git.openjdk.org/jdk/pull/13179/files/d1a8dbd1..cf71fcdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=01-02 Stats: 266 lines in 1 file changed: 0 ins; 0 del; 266 mod Patch: https://git.openjdk.org/jdk/pull/13179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13179/head:pull/13179 PR: https://git.openjdk.org/jdk/pull/13179 From jcking at openjdk.org Fri Mar 24 23:04:18 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 23:04:18 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v2] In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 18:47:06 GMT, Coleen Phillimore wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Update definition to match declaration >> >> Signed-off-by: Justin King > > src/hotspot/share/interpreter/bytecodes.cpp line 32: > >> 30: #include "utilities/bytes.hpp" >> 31: >> 32: #define JVM_BYTECODES(XX) \ > > The convention for X macros in the code is usually naming the whole macro {JVM_}BYTECODES_DO and using a lower case argument. "def" would work and look more consistent than XX. Done. > src/hotspot/share/interpreter/bytecodes.cpp line 334: > >> 332: }; >> 333: >> 334: jchar Bytecodes::_flags[(1< > Why is this not _flags[Bytecodes::number_of_codes] ? It should probably be `Bytecodes::number_of_codes * 2`. Two entry per byte-code. One for the normal format and one for wide. Wasn't sure if it was safe or some code was relying on there being exactly 512 entries even if bytecode count is less than 256. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13179#discussion_r1148130171 PR Review Comment: https://git.openjdk.org/jdk/pull/13179#discussion_r1148129268 From jcking at openjdk.org Fri Mar 24 23:10:09 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 24 Mar 2023 23:10:09 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v12] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: _CountOneBits is broken on Visual Studio before 2022 Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/167781b9..668fb06e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=10-11 Stats: 24 lines in 2 files changed: 0 ins; 20 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From cslucas at openjdk.org Fri Mar 24 23:29:29 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 24 Mar 2023 23:29:29 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com> On Fri, 24 Mar 2023 19:06:18 GMT, Vladimir Kozlov wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for SR'ing some inputs of merges used for field loads > > src/hotspot/share/opto/callnode.cpp line 1479: > >> 1477: #ifdef ASSERT >> 1478: _alloc(alloc), >> 1479: #endif > > May be we should always pass alloc, even in product VM. It is not related to your changes but it is pain to have. I can make that change. > src/hotspot/share/opto/macro.hpp line 196: > >> 194: Node* size_in_bytes); >> 195: >> 196: static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc); > > Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one. I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148141099 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148140607 From kvn at openjdk.org Fri Mar 24 23:40:31 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 24 Mar 2023 23:40:31 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com> Message-ID: On Fri, 24 Mar 2023 23:24:47 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/opto/macro.hpp line 196: >> >>> 194: Node* size_in_bytes); >>> 195: >>> 196: static Node* make_arraycopy_load(Compile* comp, PhaseIterGVN* igvn, ArrayCopyNode* ac, intptr_t offset, Node* ctl, Node* mem, BasicType ft, const Type *ftype, AllocateNode *alloc); >> >> Why you need this change? It polluted diffs and hide important changes. Could be separate change from this one. > > I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand. I see, you use it in escape.cpp. Okay. I need to review changes there too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148144963 From cslucas at openjdk.org Fri Mar 24 23:49:31 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 24 Mar 2023 23:49:31 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: <9n3UqJDruE0pvA51cFuUGal2gvluNX5LoseLuhvXlIg=.ab6692bd-3aba-4d42-a925-a15ff906677d@github.com> On Fri, 24 Mar 2023 19:53:52 GMT, Xin Liu wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for SR'ing some inputs of merges used for field loads > > src/hotspot/share/opto/callnode.hpp line 614: > >> 612: int merge_pointer_idx(JVMState* jvms) const { >> 613: assert(jvms != nullptr, "JVMS reference is null."); >> 614: return jvms->scloff() + _merge_pointer_idx; > > how about we also assert is_from_merge() here? > > Your comment above says that _merge_point_idx is a zero-based index of sfpt's input array. > here we use scloff-based. I think either is okay, but we need consistency. I think adding assert is a good idea. I'll fix the comment. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148148247 From cslucas at openjdk.org Fri Mar 24 23:59:30 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 24 Mar 2023 23:59:30 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com> On Fri, 24 Mar 2023 19:02:57 GMT, Vladimir Kozlov wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for SR'ing some inputs of merges used for field loads > > src/hotspot/share/code/debugInfo.hpp line 199: > >> 197: // ObjectValue describing an object that was scalar replaced. >> 198: >> 199: class ObjectMergeValue: public ScopeValue { > > Why you did not make subclass of ObjectValue? You would need to check `sv->is_object_merge()` first before `sv->is_object()` in few places. But on other hand you don't need to duplicates ObjectValue`s fields and asserts. Let me try that and see how it looks. > src/hotspot/share/opto/callnode.hpp line 511: > >> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation >> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how >> 511: // 'spobj' is used in both scenarios are described below. > > I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information. > I think it should be separate Node which points to array of SFSO id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field. SFSO could be created before the merge. Consider: > > Point p = new Point(); > Point q = foo(); > if (cond) { > q = p; > } > trap(p, q); I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148150933 PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148151474 From kvn at openjdk.org Sat Mar 25 00:11:31 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 25 Mar 2023 00:11:31 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> <7xRwVRVapKbqiVQMDMZUh3ILhfaYub_brXWVopFhJ8M=.28289c04-0ff0-4f19-b764-03af4d3155d6@github.com> Message-ID: On Fri, 24 Mar 2023 23:57:07 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/opto/callnode.hpp line 511: >> >>> 509: // by a SafePoint; 2) A scalar replaced object is participating in an allocation >>> 510: // merge (Phi) and the Phi is referenced by a SafePoint. The schematics of how >>> 511: // 'spobj' is used in both scenarios are described below. >> >> I am not comfortable with reusing SafePointScalarObjectNode for 2) since it describes totally different information. >> I think it should be separate Node which points to array of SFSO id (in addition to Phis) similar how we do now if SFSO is referenced in other SFSO's field. SFSO could be created before the merge. Consider: >> >> Point p = new Point(); >> Point q = foo(); >> if (cond) { >> q = p; >> } >> trap(p, q); > > I had considered that but decided not to do it to prevent adding a new IR node. I'll give that a shot and update this thread with how it goes. It **will** complicate your DebugInfo code (packing/unpacking) information. But I think it is right thing to do to avoid duplicated re-allocations during deoptimization - you should have only one new object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148154060 From cslucas at openjdk.org Sat Mar 25 00:11:34 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Sat, 25 Mar 2023 00:11:34 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> Message-ID: On Mon, 20 Mar 2023 19:23:34 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also run tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Add support for SR'ing some inputs of merges used for field loads src/hotspot/share/opto/escape.cpp line 3734: > 3732: if (reducible_merges.member(n)) { > 3733: // Split loads through phi > 3734: reduce_this_phi_on_field_access(n->as_Phi(), alloc_worklist); I decided to do the split here so that Phase 1 of `split_unique_types` could assign a new instance type for the new loads created by `split_through_phi`. However, I'm considering doing the split at the end of `compute_escape` instead of here to keep all the code that does split close together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1148153569 From duke at openjdk.org Sat Mar 25 03:59:28 2023 From: duke at openjdk.org (Jekyle) Date: Sat, 25 Mar 2023 03:59:28 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v3] In-Reply-To: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> References: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> Message-ID: On Fri, 24 Mar 2023 23:04:12 GMT, Justin King wrote: >> Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. > > Justin King has updated the pull request incrementally with two additional commits since the last revision: > > - Replace XX with def and add _DO suffix > > Signed-off-by: Justin King > - Fix compiler warnings > > Signed-off-by: Justin King Marked as reviewed by Jekyle at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/13179#pullrequestreview-1357742875 From dholmes at openjdk.org Mon Mar 27 01:28:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 01:28:29 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v2] In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 22:55:29 GMT, Justin King wrote: >> src/hotspot/share/interpreter/bytecodes.cpp line 334: >> >>> 332: }; >>> 333: >>> 334: jchar Bytecodes::_flags[(1<> >> Why is this not _flags[Bytecodes::number_of_codes] ? > > It should probably be `Bytecodes::number_of_codes * 2`. Two entry per byte-code. One for the normal format and one for wide. Wasn't sure if it was safe or some code was relying on there being exactly 512 entries even if bytecode count is less than 256. When this was put in (JDK-6939207) the flags were arranged so that the two forms were at index N and N+256 rather than index N and N+number_of_codes. That seems to remain the case today - just grep for `1< References: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> Message-ID: On Fri, 24 Mar 2023 23:04:12 GMT, Justin King wrote: >> Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. > > Justin King has updated the pull request incrementally with two additional commits since the last revision: > > - Replace XX with def and add _DO suffix > > Signed-off-by: Justin King > - Fix compiler warnings > > Signed-off-by: Justin King Changes seem okay - unfortunately a lot of noise in the PR diff that obscures actual changes. A couple of queries. Thanks. src/hotspot/share/interpreter/bytecodes.cpp line 320: > 318: }; > 319: > 320: #define STRING_SIZE(string) StringLiteralSize::invoke(string) Can't you simply use: #define STRING_SIZE(string) (sizeof(string) - 1) ? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13179#pullrequestreview-1358211876 PR Review Comment: https://git.openjdk.org/jdk/pull/13179#discussion_r1148710333 From dholmes at openjdk.org Mon Mar 27 02:39:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 02:39:31 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> Message-ID: On Fri, 24 Mar 2023 18:50:00 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Removed accidental change Changes requested by dholmes (Reviewer). src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4319: > 4317: void MacroAssembler::load_klass(Register dst, Register src) { > 4318: assert(oopDesc::klass_offset_in_bytes() < static_cast(os::vm_page_size()), > 4319: "Doesn't need explicit null check"); Sorry I meant for this to be a "global" assert somewhere, executed once per VM startup, not done on each call like this. src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3581: > 3579: > 3580: void TemplateTable::arraylength() { > 3581: assert(arrayOopDesc::length_offset_in_bytes() < static_cast(os::vm_page_size()), Ditto: "global" assertion please. ------------- PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1358241400 PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1148728658 PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1148728814 From dholmes at openjdk.org Mon Mar 27 04:40:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 04:40:34 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Fri, 24 Mar 2023 17:42:45 GMT, Matias Saavedra Silva 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/28c4b1d4...518f5409 > > Consolidating some of the simpler methods is a good idea! LGTM Thanks for the review @matias9927 ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13134#issuecomment-1484478271 From dholmes at openjdk.org Mon Mar 27 04:52:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 04:52:37 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Fri, 24 Mar 2023 18:39:41 GMT, Coleen Phillimore 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/e79dce26...518f5409 > > src/hotspot/share/cds/dynamicArchive.cpp line 383: > >> 381: ExceptionMark em(current); >> 382: ResourceMark rm(current); >> 383: HandleMark hm(current); > > Why is there a HandleMark here? Should it be lower in the call stack? It is needed before calling `MetaspaceShared::link_shared_classes`. It seemed neatest to place all the "marks" together at the start of the method. > src/hotspot/share/cds/dynamicArchive.cpp line 391: > >> 389: log_info(cds,dynamic)("Preparing for dynamic dump at exit in thread %s", current->name()); >> 390: >> 391: MetaspaceShared::link_shared_classes(false/*not from jcmd*/, current); > > link_shared_classes is declared with TRAPS, so this should have a > JavaThread* THREAD = current; > and use HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION macros. Okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1148778315 PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1148779534 From dholmes at openjdk.org Mon Mar 27 04:56:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 04:56:35 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Fri, 24 Mar 2023 18:38:43 GMT, Coleen Phillimore 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/955564c9...518f5409 > > src/hotspot/share/cds/dynamicArchive.cpp line 385: > >> 383: HandleMark hm(current); >> 384: >> 385: if (!(DynamicDumpSharedSpaces && archive_name != nullptr)) { > > Can you make this !DynamicDumpSharedSpaces || archive_name == nullptr so it's easier to read. I'm trying to figure out how archive_name relates to ArchiveClassesAtExit and why you made the switch. I changed the condition to use a temp variable that should make things clearer. `ArchiveClassesAtExit` was always passed to `dump` as the `archive_name`, so no "switch" there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1148781382 From dholmes at openjdk.org Mon Mar 27 05:01:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 05:01:30 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Mon, 27 Mar 2023 04:53:29 GMT, David Holmes wrote: >> src/hotspot/share/cds/dynamicArchive.cpp line 385: >> >>> 383: HandleMark hm(current); >>> 384: >>> 385: if (!(DynamicDumpSharedSpaces && archive_name != nullptr)) { >> >> Can you make this !DynamicDumpSharedSpaces || archive_name == nullptr so it's easier to read. I'm trying to figure out how archive_name relates to ArchiveClassesAtExit and why you made the switch. > > I changed the condition to use a temp variable that should make things clearer. > > `ArchiveClassesAtExit` was always passed to `dump` as the `archive_name`, so no "switch" there. Update: I changed the condition as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1148786154 From dholmes at openjdk.org Mon Mar 27 05:01:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 05:01:34 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Fri, 24 Mar 2023 18:39:00 GMT, Coleen Phillimore 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/0e930be9...518f5409 > > src/hotspot/share/cds/dynamicArchive.cpp line 389: > >> 387: } >> 388: >> 389: log_info(cds,dynamic)("Preparing for dynamic dump at exit in thread %s", current->name()); > > nit, needs a ' ' between cds, dynamic. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1148785914 From dholmes at openjdk.org Mon Mar 27 05:09:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 05:09:19 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v3] In-Reply-To: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: > `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). > > Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). > > Each phase can be seen in distinct commits if you prefer to see the steps involved. > > Testing: > - new ExitRace test > - all dynamicArchive tests > - tiers 1-4 > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Address Coleen's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13134/files - new: https://git.openjdk.org/jdk/pull/13134/files/518f5409..f037df96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13134&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13134&range=01-02 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13134/head:pull/13134 PR: https://git.openjdk.org/jdk/pull/13134 From dholmes at openjdk.org Mon Mar 27 05:09:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 05:09:23 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: <5Y3e9NvmMtiguAa-iIY4LwmcUcY3yOqeAX579bG3zhE=.38f49fc0-58ca-4eeb-b4f7-279ad99b693d@github.com> On Fri, 24 Mar 2023 18:40:28 GMT, Coleen Phillimore 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 12 additional commits since the last revision: >> >> - Restore comment to as it was pre JDK-8266770 >> - Update test to removing debugging code >> - Merge branch 'master' into 8304147-dynamic-dump >> - Update test comments >> - Phase 4: remove unused methods and adjust dump_for_jcmd >> - Missed removing the check at the dump_at_exit callsite. >> - Phase 3: Consolidate code into a new dump_at_exit that combines check, prepare and dump in one. >> Minor tweak to test. >> - Merge branch '8304147-test-only' into 8304147-dynamic-dump >> - Initial test >> - Phase 2: Move the dump to immediately after the prepare_for_dump >> - ... and 2 more: https://git.openjdk.org/jdk/compare/e6079399...518f5409 > > This is a very nice simplification of the JVM exit paths. I had a few minor comments. Thanks for the review @coleenp - all comments now addressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13134#issuecomment-1484498790 From adinn at openjdk.org Mon Mar 27 09:25:41 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 27 Mar 2023 09:25:41 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> Message-ID: <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> On Mon, 27 Mar 2023 02:34:37 GMT, David Holmes wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed accidental change > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4319: > >> 4317: void MacroAssembler::load_klass(Register dst, Register src) { >> 4318: assert(oopDesc::klass_offset_in_bytes() < static_cast(os::vm_page_size()), >> 4319: "Doesn't need explicit null check"); > > Sorry I meant for this to be a "global" assert somewhere, executed once per VM startup, not done on each call like this. Yes, and preferably with an accompanying comment that explains why the assert is present i.e. that it guarantees that calls to `load_klass` can rely on the SEGV handler to detect null oops. Also a similar comment for the array length offset assertion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1149033259 From jsjolen at openjdk.org Mon Mar 27 11:32:28 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 27 Mar 2023 11:32:28 GMT Subject: RFR: 8304442: Allocate VirtualMemoryTracker into Arena Message-ID: Hi, This is a suggestion to allocate the VirtualMemoryTracker memory inside of an Arena instead of on the heap. This reduces the number of NativeCallStacks allocated as VMT doesn't go through os::malloc for each linked list node. It also hopefully increases memory locality, as the nodes are in the best case allocated very close to each other. This PR sees a performance improvement in os::commit_memory and reserve_memory of about 10-25%, at no cost to reporting. ------------- Commit messages: - Replace comment style - Allocate VirtualMemoryTracker in Arena Changes: https://git.openjdk.org/jdk/pull/13190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304442 Stats: 51 lines in 2 files changed: 29 ins; 12 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13190/head:pull/13190 PR: https://git.openjdk.org/jdk/pull/13190 From coleenp at openjdk.org Mon Mar 27 11:56:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 11:56:34 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> Message-ID: <7UxOn1AbaPhIgbnqawZCeJWNy9UJK0WC-30q6NQDWFs=.9ac163aa-0047-43fe-9f14-a1e18213021c@github.com> On Mon, 27 Mar 2023 09:22:14 GMT, Andrew Dinn wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4319: >> >>> 4317: void MacroAssembler::load_klass(Register dst, Register src) { >>> 4318: assert(oopDesc::klass_offset_in_bytes() < static_cast(os::vm_page_size()), >>> 4319: "Doesn't need explicit null check"); >> >> Sorry I meant for this to be a "global" assert somewhere, executed once per VM startup, not done on each call like this. > > Yes, and preferably with an accompanying comment that explains why the assert is present i.e. that it guarantees that calls to `load_klass` can rely on the SEGV handler to detect null oops. Also a similar comment for the array length offset assertion. Suggest a global place please and but not in oopDesc::klass_offset_in_bytes() because that would require oop.hpp to include os.hpp. I couldn't find somewhere good where we wouldn't have to write a large comment to explain the context. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1149202330 From coleenp at openjdk.org Mon Mar 27 12:04:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 12:04:35 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> On Mon, 27 Mar 2023 04:46:43 GMT, David Holmes wrote: >> src/hotspot/share/cds/dynamicArchive.cpp line 383: >> >>> 381: ExceptionMark em(current); >>> 382: ResourceMark rm(current); >>> 383: HandleMark hm(current); >> >> Why is there a HandleMark here? Should it be lower in the call stack? > > It is needed before calling `MetaspaceShared::link_shared_classes`. It seemed neatest to place all the "marks" together at the start of the method. The HandleMarks should be around the code that creates and uses the handles, so GC doesn't have to collect Handles that are not needed. I don't see any Handle's escaping from link_shared_classes or any there. If you remove the HandleMark does (or where does) the code assert? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149210540 From coleenp at openjdk.org Mon Mar 27 12:09:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 12:09:35 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Mon, 27 Mar 2023 04:59:01 GMT, David Holmes wrote: >> I changed the condition to use a temp variable that should make things clearer. >> >> `ArchiveClassesAtExit` was always passed to `dump` as the `archive_name`, so no "switch" there. > > Update: I changed the condition as you suggested. Ok, I see it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149215995 From jcking at openjdk.org Mon Mar 27 14:23:09 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 14:23:09 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v2] In-Reply-To: <2hvVr1cOb4OOUHovLEJ5kIkBA3gdDPJqP6ssLcX7Z_Y=.e3893876-3882-4e0e-8a12-09d2b643c1cd@github.com> References: <2hvVr1cOb4OOUHovLEJ5kIkBA3gdDPJqP6ssLcX7Z_Y=.e3893876-3882-4e0e-8a12-09d2b643c1cd@github.com> Message-ID: On Thu, 23 Mar 2023 21:48:49 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update existing spacing since line is being touched anyway > > Signed-off-by: Justin King Looking into the macOS odd build errors before moving forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13160#issuecomment-1485197358 From jcking at openjdk.org Mon Mar 27 14:34:00 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 14:34:00 GMT Subject: RFR: JDK-8304539: Cleanup utilities/{count_leading_zeros, count_trailing_zeros, population_count}.hpp [v13] In-Reply-To: References: Message-ID: > As the title says, cleanup the mentioned headers. This is similar to `byteswap.hpp` and removes the extraneous `#ifdef` for XLC since it is really just Clang now. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update comment Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13103/files - new: https://git.openjdk.org/jdk/pull/13103/files/668fb06e..e52ce442 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13103&range=11-12 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13103/head:pull/13103 PR: https://git.openjdk.org/jdk/pull/13103 From jcking at openjdk.org Mon Mar 27 14:43:12 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 14:43:12 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v3] In-Reply-To: References: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> Message-ID: On Mon, 27 Mar 2023 01:53:13 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace XX with def and add _DO suffix >> >> Signed-off-by: Justin King >> - Fix compiler warnings >> >> Signed-off-by: Justin King > > src/hotspot/share/interpreter/bytecodes.cpp line 320: > >> 318: }; >> 319: >> 320: #define STRING_SIZE(string) StringLiteralSize::invoke(string) > > Can't you simply use: > > #define STRING_SIZE(string) (sizeof(string) - 1) > > ? No, due to `nullptr` for the `wide_format`. That was my first instinct as well, then I saw `nullptr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13179#discussion_r1149352061 From jcking at openjdk.org Mon Mar 27 14:50:47 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 14:50:47 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v4] In-Reply-To: References: Message-ID: > Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update indentation Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13179/files - new: https://git.openjdk.org/jdk/pull/13179/files/cf71fcdd..739689d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13179&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13179/head:pull/13179 PR: https://git.openjdk.org/jdk/pull/13179 From coleenp at openjdk.org Mon Mar 27 14:55:46 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 14:55:46 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v4] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 14:50:47 GMT, Justin King wrote: >> Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update indentation > > Signed-off-by: Justin King Thanks, looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13179#pullrequestreview-1359245441 From coleenp at openjdk.org Mon Mar 27 14:55:48 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 14:55:48 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v2] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 01:25:29 GMT, David Holmes wrote: >> It should probably be `Bytecodes::number_of_codes * 2`. Two entry per byte-code. One for the normal format and one for wide. Wasn't sure if it was safe or some code was relying on there being exactly 512 entries even if bytecode count is less than 256. > > When this was put in (JDK-6939207) the flags were arranged so that the two forms were at index N and N+256 rather than index N and N+number_of_codes. That seems to remain the case today - just grep for `1< References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> <7UxOn1AbaPhIgbnqawZCeJWNy9UJK0WC-30q6NQDWFs=.9ac163aa-0047-43fe-9f14-a1e18213021c@github.com> Message-ID: <6qvK-_BTM-MpH_nbuf9AUc20gsEBF1F36yYAwI6X_4M=.c422debe-f974-44a6-84e9-5e101d96e4f6@github.com> On Mon, 27 Mar 2023 11:54:10 GMT, Coleen Phillimore wrote: >> Yes, and preferably with an accompanying comment that explains why the assert is present i.e. that it guarantees that calls to `load_klass` can rely on the SEGV handler to detect null oops. Also a similar comment for the array length offset assertion. > > Suggest a global place please and but not in oopDesc::klass_offset_in_bytes() because that would require oop.hpp to include os.hpp. I couldn't find somewhere good where we wouldn't have to write a large comment to explain the context. Perhaps in `Universe::genesis()` in file universe.cpp? That is where all sorts of hand-cranked Klass-related gubbins gets set up so it seems like a sensible place to check before the create. Likewise for the array offset assert. WDYT, Coleen/David? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1149426029 From coleenp at openjdk.org Mon Mar 27 17:58:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 17:58:16 GMT Subject: RFR: 8304442: Allocate VirtualMemoryTracker into Arena In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 11:24:38 GMT, Johan Sj?len wrote: > Hi, > > This is a suggestion to allocate the VirtualMemoryTracker memory inside of an Arena instead of on the heap. This reduces the number of NativeCallStacks allocated as VMT doesn't go through os::malloc for each linked list node. It also hopefully increases memory locality, as the nodes are in the best case allocated very close to each other. > > This PR sees a performance improvement in os::commit_memory and reserve_memory of about 10-25%, at no cost to reporting. These sorted regions are never deleted? src/hotspot/share/services/virtualMemoryTracker.cpp line 120: > 118: VirtualMemoryRegion(base, size), > 119: _committed_regions(VirtualMemoryTracker::_backing_arena), > 120: _stack(NativeCallStack::empty_stack()), _flag(mtNone) { } You shouldn't record anything with mtNone (not sure if this is what this does). src/hotspot/share/services/virtualMemoryTracker.cpp line 127: > 125: _committed_regions(VirtualMemoryTracker::_backing_arena) { > 126: *this = rr; > 127: } (preexisting) since you have a copy constructor, should you have a deleted operator=? ------------- PR Review: https://git.openjdk.org/jdk/pull/13190#pullrequestreview-1359587493 PR Review Comment: https://git.openjdk.org/jdk/pull/13190#discussion_r1149602431 PR Review Comment: https://git.openjdk.org/jdk/pull/13190#discussion_r1149602739 From jcking at openjdk.org Mon Mar 27 18:16:50 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 18:16:50 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update approach to avoid implicit constructors Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13160/files - new: https://git.openjdk.org/jdk/pull/13160/files/d6afef79..7aab9bea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=01-02 Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13160/head:pull/13160 PR: https://git.openjdk.org/jdk/pull/13160 From dcubed at openjdk.org Mon Mar 27 20:16:09 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Mar 2023 20:16:09 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 18:16:50 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update approach to avoid implicit constructors > > Signed-off-by: Justin King Still thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13160#pullrequestreview-1359804193 From jcking at openjdk.org Mon Mar 27 20:24:42 2023 From: jcking at openjdk.org (Justin King) Date: Mon, 27 Mar 2023 20:24:42 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 18:16:50 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update approach to avoid implicit constructors > > Signed-off-by: Justin King Yeah, sorry had to fix how the storage was declared. Forgot that the compiler inserts the default constructor if you use a typed array. Should be good now, waiting on GHA to confirm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13160#issuecomment-1485813481 From dholmes at openjdk.org Mon Mar 27 21:18:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 21:18:42 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> Message-ID: On Mon, 27 Mar 2023 12:01:38 GMT, Coleen Phillimore wrote: >> It is needed before calling `MetaspaceShared::link_shared_classes`. It seemed neatest to place all the "marks" together at the start of the method. > > The HandleMarks should be around the code that creates and uses the handles, so GC doesn't have to collect Handles that are not needed. I don't see any Handle's escaping from link_shared_classes or any there. If you remove the HandleMark does (or where does) the code assert? Yes it asserts. I'll have to reproduce it in the morning to get the stack again (test directory was overwritten). In the old code it comes from the JVM_ENTRY for `before_halt`, as that has a HandleMarkCleaner. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149799283 From matsaave at openjdk.org Mon Mar 27 21:23:12 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 27 Mar 2023 21:23:12 GMT Subject: RFR: 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception Message-ID: The change in [JDK-8304069](https://bugs.openjdk.org/browse/JDK-8304069) resulted in an assertion failure in the case of multiple duplicate fields, methods, or interfaces. This would create unwanted pending exceptions leading to a failure later. The method will now return following a class file parse error to avoid adding more pending errors. Verified with tiers 1-6. ------------- Commit messages: - 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception Changes: https://git.openjdk.org/jdk/pull/13195/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304931 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13195.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13195/head:pull/13195 PR: https://git.openjdk.org/jdk/pull/13195 From dholmes at openjdk.org Mon Mar 27 21:31:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 21:31:08 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> Message-ID: On Mon, 27 Mar 2023 21:16:14 GMT, David Holmes wrote: >> The HandleMarks should be around the code that creates and uses the handles, so GC doesn't have to collect Handles that are not needed. I don't see any Handle's escaping from link_shared_classes or any there. If you remove the HandleMark does (or where does) the code assert? > > Yes it asserts. I'll have to reproduce it in the morning to get the stack again (test directory was overwritten). In the old code it comes from the JVM_ENTRY for `before_halt`, as that has a HandleMarkCleaner. Stack: [0x00007f22cfdae000,0x00007f22cfeaf000], sp=0x00007f22cfead390, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xf54cf4] HandleArea::allocate_handle(oop)+0x214 (handles.cpp:40) V [libjvm.so+0xab3494] ClassPrelinker::find_loaded_class(JavaThread*, oop, Symbol*)+0xb4 (handles.inline.hpp:42) V [libjvm.so+0xab42f2] ClassPrelinker::maybe_resolve_class(constantPoolHandle, int, JavaThread*)+0xd2 (classPrelinker.cpp:173) V [libjvm.so+0xab4f0e] ClassPrelinker::dumptime_resolve_constants(InstanceKlass*, JavaThread*)+0x40e (classPrelinker.cpp:134) V [libjvm.so+0x1621479] MetaspaceShared::link_shared_classes(bool, JavaThread*)+0x2f9 (metaspaceShared.cpp:621) V [libjvm.so+0xd01658] DynamicArchive::dump_at_exit(JavaThread*, char const*)+0x318 (dynamicArchive.cpp:392) V [libjvm.so+0x1064ea6] before_exit(JavaThread*, bool)+0x86 (java.cpp:445) V [libjvm.so+0x1ac8468] Threads::destroy_vm()+0x1b8 (threads.cpp:1085) V [libjvm.so+0x118be7d] jni_DestroyJavaVM+0xad (jni.cpp:3735) @coleenp I'm going to assume you will say that there is a missing HM in the ClassPrelinker code. If so I will file an issue for that and add it to this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149808354 From coleenp at openjdk.org Mon Mar 27 21:34:47 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 21:34:47 GMT Subject: RFR: 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 19:51:27 GMT, Matias Saavedra Silva wrote: > The change in [JDK-8304069](https://bugs.openjdk.org/browse/JDK-8304069) resulted in an assertion failure in the case of multiple duplicate fields, methods, or interfaces. This would create unwanted pending exceptions leading to a failure later. > > The method will now return following a class file parse error to avoid adding more pending errors. Verified with tiers 1-6. Looks good plus trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13195#pullrequestreview-1359900546 From coleenp at openjdk.org Mon Mar 27 21:38:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 21:38:37 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v3] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: On Mon, 27 Mar 2023 05:09:19 GMT, David Holmes wrote: >> `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). >> >> Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). >> >> Each phase can be seen in distinct commits if you prefer to see the steps involved. >> >> Testing: >> - new ExitRace test >> - all dynamicArchive tests >> - tiers 1-4 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Address Coleen's comments Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13134#pullrequestreview-1359904546 From coleenp at openjdk.org Mon Mar 27 21:38:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Mar 2023 21:38:38 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> Message-ID: On Mon, 27 Mar 2023 21:28:12 GMT, David Holmes wrote: >> Yes it asserts. I'll have to reproduce it in the morning to get the stack again (test directory was overwritten). In the old code it comes from the JVM_ENTRY for `before_halt`, as that has a HandleMarkCleaner. > > Stack: [0x00007f22cfdae000,0x00007f22cfeaf000], sp=0x00007f22cfead390, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xf54cf4] HandleArea::allocate_handle(oop)+0x214 (handles.cpp:40) > V [libjvm.so+0xab3494] ClassPrelinker::find_loaded_class(JavaThread*, oop, Symbol*)+0xb4 (handles.inline.hpp:42) > V [libjvm.so+0xab42f2] ClassPrelinker::maybe_resolve_class(constantPoolHandle, int, JavaThread*)+0xd2 (classPrelinker.cpp:173) > V [libjvm.so+0xab4f0e] ClassPrelinker::dumptime_resolve_constants(InstanceKlass*, JavaThread*)+0x40e (classPrelinker.cpp:134) > V [libjvm.so+0x1621479] MetaspaceShared::link_shared_classes(bool, JavaThread*)+0x2f9 (metaspaceShared.cpp:621) > V [libjvm.so+0xd01658] DynamicArchive::dump_at_exit(JavaThread*, char const*)+0x318 (dynamicArchive.cpp:392) > V [libjvm.so+0x1064ea6] before_exit(JavaThread*, bool)+0x86 (java.cpp:445) > V [libjvm.so+0x1ac8468] Threads::destroy_vm()+0x1b8 (threads.cpp:1085) > V [libjvm.so+0x118be7d] jni_DestroyJavaVM+0xad (jni.cpp:3735) > > @coleenp I'm going to assume you will say that there is a missing HM in the ClassPrelinker code. If so I will file an issue for that and add it to this PR. Okay, thank you. It's good you found the handle. Yes, you can file another PR to move the HM down and leave this as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149813391 From dholmes at openjdk.org Mon Mar 27 21:48:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 21:48:33 GMT Subject: RFR: 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 19:51:27 GMT, Matias Saavedra Silva wrote: > The change in [JDK-8304069](https://bugs.openjdk.org/browse/JDK-8304069) resulted in an assertion failure in the case of multiple duplicate fields, methods, or interfaces. This would create unwanted pending exceptions leading to a failure later. > > The method will now return following a class file parse error to avoid adding more pending errors. Verified with tiers 1-6. Looks good. I'd expected to see CHECK used but we know there is an exception pending so use of the macro to add a check for that is redundant, so the return works better. Thanks. This is trivial enough to not need 24 hour wait. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13195#pullrequestreview-1359914666 From dholmes at openjdk.org Mon Mar 27 22:05:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 22:05:34 GMT Subject: RFR: 8304147: JVM crash during shutdown when dumping dynamic archive [v2] In-Reply-To: References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> <1RyCbKC7gm0NxP7Zl6VbuLXkv8MdQQ9ug6IML8uay48=.72477211-e6c6-4b37-ac7d-f8f4cfbe867b@github.com> Message-ID: <8XRVwgl0uAt6Qbq9hgZEK0CRcgKt_mQ75yaMUP1vdog=.cb9e20d5-e12c-4e4d-a2df-63e2990e358f@github.com> On Mon, 27 Mar 2023 21:35:19 GMT, Coleen Phillimore wrote: >> Stack: [0x00007f22cfdae000,0x00007f22cfeaf000], sp=0x00007f22cfead390, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0xf54cf4] HandleArea::allocate_handle(oop)+0x214 (handles.cpp:40) >> V [libjvm.so+0xab3494] ClassPrelinker::find_loaded_class(JavaThread*, oop, Symbol*)+0xb4 (handles.inline.hpp:42) >> V [libjvm.so+0xab42f2] ClassPrelinker::maybe_resolve_class(constantPoolHandle, int, JavaThread*)+0xd2 (classPrelinker.cpp:173) >> V [libjvm.so+0xab4f0e] ClassPrelinker::dumptime_resolve_constants(InstanceKlass*, JavaThread*)+0x40e (classPrelinker.cpp:134) >> V [libjvm.so+0x1621479] MetaspaceShared::link_shared_classes(bool, JavaThread*)+0x2f9 (metaspaceShared.cpp:621) >> V [libjvm.so+0xd01658] DynamicArchive::dump_at_exit(JavaThread*, char const*)+0x318 (dynamicArchive.cpp:392) >> V [libjvm.so+0x1064ea6] before_exit(JavaThread*, bool)+0x86 (java.cpp:445) >> V [libjvm.so+0x1ac8468] Threads::destroy_vm()+0x1b8 (threads.cpp:1085) >> V [libjvm.so+0x118be7d] jni_DestroyJavaVM+0xad (jni.cpp:3735) >> >> @coleenp I'm going to assume you will say that there is a missing HM in the ClassPrelinker code. If so I will file an issue for that and add it to this PR. > > Okay, thank you. It's good you found the handle. Yes, you can file another RFE to move the HM down and leave this as is. Seems there are a couple of paths missing the HM so I will leave as-is and file follow-up issues. Thanks for the review @coleenp ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13134#discussion_r1149832304 From dholmes at openjdk.org Mon Mar 27 22:08:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Mar 2023 22:08:48 GMT Subject: Integrated: 8304147: JVM crash during shutdown when dumping dynamic archive In-Reply-To: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> References: <-QNB91rpYAEZmAnJsqwEHj4vg5eJK3xv5LxZz8V1jRg=.4bb6d822-3f41-4737-8950-5864ca1d8df9@github.com> Message-ID: <7YvHk1qyw3o7iY8_QqVAIol0KDXiwJiF0nDyOsIcdrU=.1149c3ec-84d9-42ef-b777-2abe33b8e6e4@github.com> On Wed, 22 Mar 2023 05:03:50 GMT, David Holmes wrote: > `DynamicArchive::prepare_for_dump_at_exit()` could be called concurrently on the two VM exit paths, leading either to assertion failures in debug builds, or a crash in product build when the actual dump occurred. The basic fix was to move the `DynamicArchive::prepare_for_dump_at_exit()` functionality into `before_exit` (java.cpp) where it can only be executed by one thread - thus avoiding the race (Phase 1). > > Once that is done we can move the actual dump operation to be co-located with the `prepare_for_dump_at_exit()` (Phase 2) and then consolidate that code by refactoring it into a new `DynamicArchive::dump_at_exit()` method (Phase 3), and then removing the leftover methods that are no longer needed (Phase 4). > > Each phase can be seen in distinct commits if you prefer to see the steps involved. > > Testing: > - new ExitRace test > - all dynamicArchive tests > - tiers 1-4 > > Thanks. This pull request has now been integrated. Changeset: 63ce88b5 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/63ce88b5fbc8e2b9be01a135156885000bc5c48d Stats: 211 lines in 7 files changed: 156 ins; 43 del; 12 mod 8304147: JVM crash during shutdown when dumping dynamic archive Reviewed-by: ccheung, matsaave, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/13134 From matsaave at openjdk.org Mon Mar 27 22:15:43 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 27 Mar 2023 22:15:43 GMT Subject: RFR: 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception In-Reply-To: References: Message-ID: <7uxZR0KBXlPu_pVqlGJyud34J_-sm8V_o6X_o5UXSk0=.ccdc79f0-a5e2-468d-bbc5-b6096560709a@github.com> On Mon, 27 Mar 2023 21:32:21 GMT, Coleen Phillimore wrote: >> The change in [JDK-8304069](https://bugs.openjdk.org/browse/JDK-8304069) resulted in an assertion failure in the case of multiple duplicate fields, methods, or interfaces. This would create unwanted pending exceptions leading to a failure later. >> >> The method will now return following a class file parse error to avoid adding more pending errors. Verified with tiers 1-6. > > Looks good plus trivial. Thank you for the reviews @coleenp and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/13195#issuecomment-1485926067 From matsaave at openjdk.org Mon Mar 27 22:15:45 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 27 Mar 2023 22:15:45 GMT Subject: Integrated: 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 19:51:27 GMT, Matias Saavedra Silva wrote: > The change in [JDK-8304069](https://bugs.openjdk.org/browse/JDK-8304069) resulted in an assertion failure in the case of multiple duplicate fields, methods, or interfaces. This would create unwanted pending exceptions leading to a failure later. > > The method will now return following a class file parse error to avoid adding more pending errors. Verified with tiers 1-6. This pull request has now been integrated. Changeset: 6aec6f3a Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/6aec6f3a842ead30b26cd31dc57a2ab268f67875 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8304931: vm/concepts/methods/methods001/methods00101m1/methods00101m1 failures with already pending exception Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13195 From dholmes at openjdk.org Tue Mar 28 02:43:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 02:43:33 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: <6qvK-_BTM-MpH_nbuf9AUc20gsEBF1F36yYAwI6X_4M=.c422debe-f974-44a6-84e9-5e101d96e4f6@github.com> References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> <7UxOn1AbaPhIgbnqawZCeJWNy9UJK0WC-30q6NQDWFs=.9ac163aa-0047-43fe-9f14-a1e18213021c@github.com> <6qvK-_BTM-MpH_nbuf9AUc20gsEBF1F36yYAwI6X_4M=.c422debe-f974-44a6-84e9-5e101d96e4f6@github.com> Message-ID: On Mon, 27 Mar 2023 15:28:52 GMT, Andrew Dinn wrote: >> Suggest a global place please and but not in oopDesc::klass_offset_in_bytes() because that would require oop.hpp to include os.hpp. I couldn't find somewhere good where we wouldn't have to write a large comment to explain the context. > > Perhaps in `Universe::genesis()` in file universe.cpp? That is where all sorts of hand-cranked Klass-related gubbins gets set up so it seems like a sensible place to check before the create. Likewise for the array offset assert. > > WDYT, Coleen/David? That sounds okay to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1149965645 From dholmes at openjdk.org Tue Mar 28 05:07:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 05:07:31 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 18:16:50 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update approach to avoid implicit constructors > > Signed-off-by: Justin King src/hotspot/share/runtime/synchronizer.cpp line 255: > 253: // by property of the storage itself being aligned to that requirement and each entry storage being > 254: // `sizeof(PlatformMutex)` aligned up to `alignof(PlatformMutex)`. > 255: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][align_up(sizeof(PlatformMutex), alignof(PlatformMutex))]; I'm afraid you lost me here. Why does this have to be so convoluted/obscure? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1150031083 From dholmes at openjdk.org Tue Mar 28 05:17:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 05:17:31 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v4] In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 14:50:47 GMT, Justin King wrote: >> Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Update indentation > > Signed-off-by: Justin King Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13179#pullrequestreview-1360218500 From dholmes at openjdk.org Tue Mar 28 05:17:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 05:17:33 GMT Subject: RFR: JDK-8304884: Update Bytecodes data to be mostly compile time constants [v3] In-Reply-To: References: <5kKspPexAeblT7Hwo0jtKXBofFvWslrJ4Hs0vqFA87o=.db23d3e2-9b67-4868-ae11-8d69d2bfce7f@github.com> Message-ID: On Mon, 27 Mar 2023 14:40:02 GMT, Justin King wrote: >> src/hotspot/share/interpreter/bytecodes.cpp line 320: >> >>> 318: }; >>> 319: >>> 320: #define STRING_SIZE(string) StringLiteralSize::invoke(string) >> >> Can't you simply use: >> >> #define STRING_SIZE(string) (sizeof(string) - 1) >> >> ? > > No, due to `nullptr` for the `wide_format`. That was my first instinct as well, then I saw `nullptr`. Ah I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13179#discussion_r1150036098 From jsjolen at openjdk.org Tue Mar 28 08:54:32 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 28 Mar 2023 08:54:32 GMT Subject: RFR: 8304442: Allocate VirtualMemoryTracker into Arena In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 17:49:30 GMT, Coleen Phillimore wrote: >> Hi, >> >> This is a suggestion to allocate the VirtualMemoryTracker memory inside of an Arena instead of on the heap. This reduces the number of NativeCallStacks allocated as VMT doesn't go through os::malloc for each linked list node. It also hopefully increases memory locality, as the nodes are in the best case allocated very close to each other. >> >> This PR sees a performance improvement in os::commit_memory and reserve_memory of about 10-25%, at no cost to reporting. > > src/hotspot/share/services/virtualMemoryTracker.cpp line 120: > >> 118: VirtualMemoryRegion(base, size), >> 119: _committed_regions(VirtualMemoryTracker::_backing_arena), >> 120: _stack(NativeCallStack::empty_stack()), _flag(mtNone) { } > > You shouldn't record anything with mtNone (not sure if this is what this does). `mtNone` just signifies that the `_flag` is unused in this case (it's also pre-existing).' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13190#discussion_r1150251286 From jsjolen at openjdk.org Tue Mar 28 08:59:32 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 28 Mar 2023 08:59:32 GMT Subject: RFR: 8304442: Allocate VirtualMemoryTracker into Arena In-Reply-To: References: Message-ID: On Mon, 27 Mar 2023 17:55:27 GMT, Coleen Phillimore wrote: > These sorted regions are never deleted? They are, via `VMT::remove_released_region`. > src/hotspot/share/services/virtualMemoryTracker.cpp line 127: > >> 125: _committed_regions(VirtualMemoryTracker::_backing_arena) { >> 126: *this = rr; >> 127: } > > (preexisting) since you have a copy constructor, should you have a deleted operator=? Yeah, I also thought it was weird that Rule-of-3 isn't obeyed here. Just at a glance, seems like the default destructor does the right thing (calling destructor for each member). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13190#issuecomment-1486471985 PR Review Comment: https://git.openjdk.org/jdk/pull/13190#discussion_r1150255012 From aboldtch at openjdk.org Tue Mar 28 11:43:33 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 28 Mar 2023 11:43:33 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 05:04:37 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Update approach to avoid implicit constructors >> >> Signed-off-by: Justin King > > src/hotspot/share/runtime/synchronizer.cpp line 255: > >> 253: // by property of the storage itself being aligned to that requirement and each entry storage being >> 254: // `sizeof(PlatformMutex)` aligned up to `alignof(PlatformMutex)`. >> 255: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][align_up(sizeof(PlatformMutex), alignof(PlatformMutex))]; > > I'm afraid you lost me here. Why does this have to be so convoluted/obscure? I thought `sizeof(T)` always was a multiple of `alignof(T)`. Is there some case where this is not true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1150461135 From stuefe at openjdk.org Tue Mar 28 12:01:30 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 28 Mar 2023 12:01:30 GMT Subject: RFR: 8304442: Allocate VirtualMemoryTracker into Arena In-Reply-To: References: Message-ID: <6rGPhyO-T9mGA0tYo78DXuFpjwg8ZASfmLsPNYWUGWI=.0ba9d5e9-2cbd-4fff-a7b7-75715e1a99c2@github.com> On Tue, 28 Mar 2023 08:56:43 GMT, Johan Sj?len wrote: > > These sorted regions are never deleted? > > They are, via `VMT::remove_released_region`. I don't understand then; would this not leak memory if we randomly remove regions? Since with an Arena, you only can effectively reclaim the topmost allocation? Easy check: call os::reserve_memory/commit_memory a million times with random - and disjunct - address ranges. If RSS stays stable, we are good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13190#issuecomment-1486734277 From jcking at openjdk.org Tue Mar 28 13:29:01 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 28 Mar 2023 13:29:01 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary align_up Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13160/files - new: https://git.openjdk.org/jdk/pull/13160/files/7aab9bea..ff6e9d1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13160&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13160/head:pull/13160 PR: https://git.openjdk.org/jdk/pull/13160 From jcking at openjdk.org Tue Mar 28 13:29:04 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 28 Mar 2023 13:29:04 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v3] In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 11:40:42 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 255: >> >>> 253: // by property of the storage itself being aligned to that requirement and each entry storage being >>> 254: // `sizeof(PlatformMutex)` aligned up to `alignof(PlatformMutex)`. >>> 255: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][align_up(sizeof(PlatformMutex), alignof(PlatformMutex))]; >> >> I'm afraid you lost me here. Why does this have to be so convoluted/obscure? > > I thought `sizeof(T)` always was a multiple of `alignof(T)`. Is there some case where this is not true? Ah, I had assumed it wasn't required. But a quick glance says it is. So I'll remove the `align_up`. Should be more simple now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1150606641 From jcking at openjdk.org Tue Mar 28 14:20:17 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 28 Mar 2023 14:20:17 GMT Subject: Integrated: JDK-8304884: Update Bytecodes data to be mostly compile time constants In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 16:14:50 GMT, Justin King wrote: > Change uses a few tricks to make most of the data in Bytecodes compile time constant, avoiding the overhead during VM initialization. `Bytecodes:_flags` likely can be made compile time constant as well using `constexpr` tricks, but that is out of scope for this specific PR. This pull request has now been integrated. Changeset: 32ef4521 Author: Justin King URL: https://git.openjdk.org/jdk/commit/32ef45213223d689afdc307e96468b3621171a26 Stats: 591 lines in 2 files changed: 299 ins; 263 del; 29 mod 8304884: Update Bytecodes data to be mostly compile time constants Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13179 From jcking at openjdk.org Tue Mar 28 15:18:00 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 28 Mar 2023 15:18:00 GMT Subject: RFR: JDK-8305090: Some NMT tests broken when running under ASan Message-ID: This change fixes or skips some NMT tests when running under ASan, as well as fixing a leak. - `allocator_may_return_null=1` is added as the default is `0`, meaning ASan will never return `nullptr` and will instead crash. NMT tests check that large allocations return `nullptr` so those do not work under ASan currently. - We skip tests that intentionally access memory outside the allocated range or do things that ASan will catch, causing the tests to fail. - Fix a memory leak in `test_nmtpreinit.cpp`. - Enable coredumps to work on some platforms with ASan, some other tests rely on this working. All of this is related to ASan and NMT, so I opted to do it in a single change. ------------- Commit messages: - Fix NMT tests running under ASan Changes: https://git.openjdk.org/jdk/pull/13208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305090 Stats: 30 lines in 5 files changed: 27 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13208/head:pull/13208 PR: https://git.openjdk.org/jdk/pull/13208 From dcubed at openjdk.org Tue Mar 28 16:00:24 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Mar 2023 16:00:24 GMT Subject: RFR: 8256302: releasing oopStorage when deflating allows for faster deleting [v2] In-Reply-To: References: Message-ID: <4S4AaJUIxeScNzQc_R9Mii3MS_-bld0Qfa-hcGvnkeM=.d998eeab-e866-4337-a5a0-857df12e3801@github.com> On Fri, 2 Dec 2022 21:49:29 GMT, Daniel D. Daugherty wrote: >> Releasing ObjectMonitor oopStorage earlier when deflating allows ObjectMonitor >> deletion by a JavaThread (usually the MonitorDeflationThread) to happen while a >> ThreadBlockInVM helper is in place. This should improve time-to-safepoint. > > Daniel D. Daugherty 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: > > - address the easy dholmes and kimbarrett CR comments > - Merge branch 'JDK-8291418' into JDK-8256302 > - Merge branch 'JDK-8291418' into JDK-8256302 > - 8256302: releasing oopStorage when deflating allows for faster deleting Not yet bot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11296#issuecomment-1487190394 From dcubed at openjdk.org Tue Mar 28 19:45:35 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Mar 2023 19:45:35 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: <3jqqY35JQKt9-jNsPA8nZqThGMEilJsffvjRfCTCXlc=.00495439-81da-4dd6-84da-4441a05e5625@github.com> On Tue, 28 Mar 2023 13:29:01 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary align_up > > Signed-off-by: Justin King Still good. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13160#pullrequestreview-1361797770 From dholmes at openjdk.org Tue Mar 28 22:11:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 22:11:29 GMT Subject: RFR: 8304996: Add missing Handlemarks Message-ID: The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. Testing: tiers 1-4 Thanks. ------------- Commit messages: - Fix up HandleMarks Changes: https://git.openjdk.org/jdk/pull/13215/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13215&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304996 Stats: 13 lines in 4 files changed: 10 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13215/head:pull/13215 PR: https://git.openjdk.org/jdk/pull/13215 From coleenp at openjdk.org Tue Mar 28 22:47:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Mar 2023 22:47:28 GMT Subject: RFR: 8304996: Add missing Handlemarks In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 20:51:46 GMT, David Holmes wrote: > The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. > > Testing: tiers 1-4 > > Thanks. Looks good! thank you for fixing these. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13215#pullrequestreview-1362011184 From coleenp at openjdk.org Tue Mar 28 23:31:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 28 Mar 2023 23:31:34 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v5] In-Reply-To: References: <0lem2stXNevV-SesJmt0K5l7A6SQa8qY6XbCEwl6NIw=.7539b88a-74f1-404e-9c32-31c325a6c532@github.com> <0TTKxmiwcj6Q_qdMJhVMrku9foFY_4TnBSe7ROs9SX0=.e567e420-8fbf-4c1a-9711-bbbc621f713a@github.com> <7UxOn1AbaPhIgbnqawZCeJWNy9UJK0WC-30q6NQDWFs=.9ac163aa-0047-43fe-9f14-a1e18213021c@github.com> <6qvK-_BTM-MpH_nbuf9AUc20gsEBF1F36yYAwI6X_4M=.c422debe-f974-44a6-84e9-5e101d96e4f6@github.com> Message-ID: On Tue, 28 Mar 2023 02:41:02 GMT, David Holmes wrote: >> Perhaps in `Universe::genesis()` in file universe.cpp? That is where all sorts of hand-cranked Klass-related gubbins gets set up so it seems like a sensible place to check before the create. Likewise for the array offset assert. >> >> WDYT, Coleen/David? > > That sounds okay to me. Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1151246604 From dholmes at openjdk.org Tue Mar 28 23:54:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Mar 2023 23:54:29 GMT Subject: RFR: 8304996: Add missing Handlemarks In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 22:44:17 GMT, Coleen Phillimore wrote: >> The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. >> >> Testing: tiers 1-4 >> >> Thanks. > > Looks good! thank you for fixing these. Thanks @coleenp ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1487752123 From dholmes at openjdk.org Wed Mar 29 02:44:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Mar 2023 02:44:34 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 13:29:01 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary align_up > > Signed-off-by: Justin King src/hotspot/share/runtime/synchronizer.cpp line 253: > 251: > 252: // Static storage for an array of PlatformMutex. > 253: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][sizeof(PlatformMutex)]; Sorry I am still not understanding why this can't just be: alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()]; ??? (And is the alignas even needed?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1151334769 From shade at openjdk.org Wed Mar 29 08:43:03 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Mar 2023 08:43:03 GMT Subject: RFR: 8304996: Add missing Handlemarks In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 20:51:46 GMT, David Holmes wrote: > The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. > > Testing: tiers 1-4 > > Thanks. I think the issue synopsis should be capitalized: "Add missing HandleMarks". Also, does it cover the cases that were not covered by `dump_at_exit` `HandleMark` before? If not, then it is not adding "missing" HMs. src/hotspot/share/oops/klassVtable.cpp line 1178: > 1176: > 1177: assert(_size_method_table == supers->length(), "wrong size"); > 1178: HandleMark hm(THREAD); Question: Would this make the handles area grow up to `_size_method_table` in the worst case? I thought we want to have `HandleMark`-s closer to actual handle creation/last-use to keep the footprint at bay. ------------- PR Review: https://git.openjdk.org/jdk/pull/13215#pullrequestreview-1362538364 PR Review Comment: https://git.openjdk.org/jdk/pull/13215#discussion_r1151584904 From aboldtch at openjdk.org Wed Mar 29 11:25:23 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 29 Mar 2023 11:25:23 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 02:41:32 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary align_up >> >> Signed-off-by: Justin King > > src/hotspot/share/runtime/synchronizer.cpp line 253: > >> 251: >> 252: // Static storage for an array of PlatformMutex. >> 253: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][sizeof(PlatformMutex)]; > > Sorry I am still not understanding why this can't just be: > > alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()]; > > ??? (And is the alignas even needed?) `alignas` is not needed in your example. I guess we do not do this because we want to control the initialization of these objects and not rely on C++ dynamic initialization. You could solve this in different ways. Some containing struct, which was rejected in the #13143. Or rewriting PlatformMutex to be constant initializable. Having a byte blob as backing storage does seem like the simplest least intrusive solution. When we move to C++17 then this could be a candidate use for `std::optional`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1151783335 From jcking at openjdk.org Wed Mar 29 14:27:56 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 29 Mar 2023 14:27:56 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 11:22:55 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 253: >> >>> 251: >>> 252: // Static storage for an array of PlatformMutex. >>> 253: alignas(PlatformMutex) static uint8_t _inflation_locks[inflation_lock_count()][sizeof(PlatformMutex)]; >> >> Sorry I am still not understanding why this can't just be: >> >> alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()]; >> >> ??? (And is the alignas even needed?) > > `alignas` is not needed in your example. > > I guess we do not do this because we want to control the initialization of these objects and not rely on C++ dynamic initialization. > > You could solve this in different ways. Some containing struct, which was rejected in the #13143. Or rewriting PlatformMutex to be constant initializable. > > Having a byte blob as backing storage does seem like the simplest least intrusive solution. > > When we move to C++17 then this could be a candidate use for `std::optional`. `alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()];` will not work as the compiler will use default initialization for the array, causing the constructor of PlatformMutex to be called during library loading by the dynamic linker. With the current `uint8_t` usage, we have to ensure the compiler places the array at a suitable aligned boundary for `PlatformMutex` otherwise its free to place it at `alignas(uint8_t)` AFAIK, which can be 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1152030327 From iklam at openjdk.org Wed Mar 29 16:58:51 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Mar 2023 16:58:51 GMT Subject: RFR: 8301106 allow cds interned strings to be moved by gc [v5] In-Reply-To: References: Message-ID: > **Background:** > > Currently, the archived java strings are mapped in the G1 "[closed archive](https://github.com/openjdk/jdk/blob/574b48c6925ebfb31345fc46c7d23aa4153f99b0/src/hotspot/share/gc/g1/heapRegionType.hpp#L80-L92)" region. This essentially pins all the strings in memory. > > As a prerequisite for ([JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263)), this PR removes the requirement of pinning the archived strings. This will allow the CDS archive heap to be mapped in garbage collectors that do not support object pinning. > > **Code changes:** > > - The archived strings are referenced through an objArray (`_shared_strings_array`) to keep them alive. As a result, it's no longer necessary to pin them. > - Since it's possible for the GC to move these strings, the `_shared_table` in stringTable.cpp is modified to store a 32-bit index for each archived string. This index is used to retrieve the archived string from `_shared_strings_array` at runtime. > > Note that CDS has a limit on the size of archived objArrays. When there's a large number of strings, we use a two-level table. See the comments around `_shared_strings_array` in the header file. > > **Testing** > > Tiers 1 - 4 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 10 additional commits since the last revision: - fixed merge - Merge branch 'master' into 8301106-allow-cds-interned-strings-to-be-moved-by-gc - fixed "optimized" build - @ashu-mehra and @dholmes-ora review -- better assert and error checking for large objects; added StringTable::verify_secondary_array_index_bits() - @dholmes-ora comments - renamed obsolete functions to ArchiveHeapLoader::is_in_use() - fixed typos in comment - cleanup2 - cleanup - 8301106: Allow archived Java strings to be moved by the collector ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12607/files - new: https://git.openjdk.org/jdk/pull/12607/files/1ea3dde0..934d67f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12607&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12607&range=03-04 Stats: 375841 lines in 3206 files changed: 225901 ins; 124148 del; 25792 mod Patch: https://git.openjdk.org/jdk/pull/12607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12607/head:pull/12607 PR: https://git.openjdk.org/jdk/pull/12607 From dholmes at openjdk.org Wed Mar 29 21:50:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Mar 2023 21:50:39 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: > The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. > > Testing: tiers 1-4 > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Shipilev feedback - moved HMs back inside the loops. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13215/files - new: https://git.openjdk.org/jdk/pull/13215/files/0ffe0f20..f6ed1926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13215&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13215&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13215/head:pull/13215 PR: https://git.openjdk.org/jdk/pull/13215 From dholmes at openjdk.org Wed Mar 29 21:50:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Mar 2023 21:50:58 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 08:39:53 GMT, Aleksey Shipilev wrote: > I think the issue synopsis should be capitalized: "Add missing HandleMarks". Also, does it cover the cases that were not covered by `dump_at_exit` `HandleMark` before? If not, then it is not adding "missing" HMs. Fixed capitalization in HandleMark. Not sure what your issue is with "missing" - the HM's were not present where the Handles were used and hence were missing. Some cases were directly detected by removing the old HM in `dump_for_exit` but I also checked those files for other cases and added them. > src/hotspot/share/oops/klassVtable.cpp line 1178: > >> 1176: >> 1177: assert(_size_method_table == supers->length(), "wrong size"); >> 1178: HandleMark hm(THREAD); > > Question: Would this make the handles area grow up to `_size_method_table` in the worst case? I thought we want to have `HandleMark`-s closer to actual handle creation/last-use to keep the footprint at bay. I was optimising for runtime performance rather than footprint, but you are right this could grow in a way we don't want. So I reverted this change and made a similar change to `klassVtable::check_constraints`. Thanks for looking at this @shipilev . ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1489362742 PR Review Comment: https://git.openjdk.org/jdk/pull/13215#discussion_r1152511587 From iklam at openjdk.org Wed Mar 29 23:46:25 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Mar 2023 23:46:25 GMT Subject: RFR: 8301106: Allow archived Java strings to be moved by GC [v4] In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 23:38:13 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra and @dholmes-ora review -- better assert and error checking for large objects; added StringTable::verify_secondary_array_index_bits() > > lgtm! Thanks @ashu-mehra and @dholmes-ora for the review. I merged with latest repo and passed tiers 1~4. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12607#issuecomment-1489477106 From iklam at openjdk.org Wed Mar 29 23:46:27 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Mar 2023 23:46:27 GMT Subject: Integrated: 8301106: Allow archived Java strings to be moved by GC In-Reply-To: References: Message-ID: On Thu, 16 Feb 2023 19:14:15 GMT, Ioi Lam wrote: > **Background:** > > Currently, the archived java strings are mapped in the G1 "[closed archive](https://github.com/openjdk/jdk/blob/574b48c6925ebfb31345fc46c7d23aa4153f99b0/src/hotspot/share/gc/g1/heapRegionType.hpp#L80-L92)" region. This essentially pins all the strings in memory. > > As a prerequisite for ([JDK-8296263](https://bugs.openjdk.org/browse/JDK-8296263)), this PR removes the requirement of pinning the archived strings. This will allow the CDS archive heap to be mapped in garbage collectors that do not support object pinning. > > **Code changes:** > > - The archived strings are referenced through an objArray (`_shared_strings_array`) to keep them alive. As a result, it's no longer necessary to pin them. > - Since it's possible for the GC to move these strings, the `_shared_table` in stringTable.cpp is modified to store a 32-bit index for each archived string. This index is used to retrieve the archived string from `_shared_strings_array` at runtime. > > Note that CDS has a limit on the size of archived objArrays. When there's a large number of strings, we use a two-level table. See the comments around `_shared_strings_array` in the header file. > > **Testing** > > Tiers 1 - 4 This pull request has now been integrated. Changeset: b524a741 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/b524a74165a901383c00fbfcbc3e842c0df02398 Stats: 310 lines in 13 files changed: 165 ins; 73 del; 72 mod 8301106: Allow archived Java strings to be moved by GC Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12607 From iklam at openjdk.org Thu Mar 30 00:49:22 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 30 Mar 2023 00:49:22 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: <9jgkckXjq81MeXm2N2DsqJvReGAHSbwQx2YUme2JYfI=.9287cdcf-7ac3-4e9a-a7b1-2ca12bc8d75a@github.com> On Wed, 29 Mar 2023 21:50:39 GMT, David Holmes wrote: >> The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. >> >> Testing: tiers 1-4 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Shipilev feedback - moved HMs back inside the loops. What are the rules for using HandleMarks? In the HotSpot code, there are plenty of cases where we create a HandleMark without creating any Handles in the immediately following code. There are also plenty of cases where Handles are created in functions that do not have any HandleMarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1489527586 From dholmes at openjdk.org Thu Mar 30 01:15:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Mar 2023 01:15:18 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: <9jgkckXjq81MeXm2N2DsqJvReGAHSbwQx2YUme2JYfI=.9287cdcf-7ac3-4e9a-a7b1-2ca12bc8d75a@github.com> References: <9jgkckXjq81MeXm2N2DsqJvReGAHSbwQx2YUme2JYfI=.9287cdcf-7ac3-4e9a-a7b1-2ca12bc8d75a@github.com> Message-ID: <1ibvDNG_Vs1RNuLq5tH3Nwv-9sjb8hwY_7zzDFN0hZg=.d6e0076b-773b-443b-9738-a988649bfeea@github.com> On Thu, 30 Mar 2023 00:46:08 GMT, Ioi Lam wrote: > What are the rules for using HandleMarks? In the HotSpot code, there are plenty of cases where we create a HandleMark without creating any Handles in the immediately following code. There are also plenty of cases where Handles are created in functions that do not have any HandleMarks. @coleenp has a lot to say on this but basically HM's should appear along-side the code that creates the Handles. Unless you return a Handle from a function, there should generally be a HM in the function. There is a lot of code that doesn't follow this. Partly I think this is because we have some high-on-the-stack HMs or HandleMarkCleaners that hide the creation of Handles without a local HandleMark. Conversely if new code uses existing code that doesn't have a HM and gets an error, then the typical response is to put a HM in the new code - especially because that only affects the new change, whereas putting a HM lower-down could be seen as disruptive etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1489543752 From dholmes at openjdk.org Thu Mar 30 05:39:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Mar 2023 05:39:16 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 14:24:51 GMT, Justin King wrote: >> `alignas` is not needed in your example. >> >> I guess we do not do this because we want to control the initialization of these objects and not rely on C++ dynamic initialization. >> >> You could solve this in different ways. Some containing struct, which was rejected in the #13143. Or rewriting PlatformMutex to be constant initializable. >> >> Having a byte blob as backing storage does seem like the simplest least intrusive solution. >> >> When we move to C++17 then this could be a candidate use for `std::optional`. > > `alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()];` will not work as the compiler will use default initialization for the array, causing the constructor of PlatformMutex to be called during library loading by the dynamic linker. > > With the current `uint8_t` usage, we have to ensure the compiler places the array at a suitable aligned boundary for `PlatformMutex` otherwise its free to place it at `alignas(uint8_t)` AFAIK, which can be 1. Ugghh sorry not thinking in C++ - forgot about the implicit initialization in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1152755970 From duke at openjdk.org Thu Mar 30 06:31:18 2023 From: duke at openjdk.org (Deepa Kumari) Date: Thu, 30 Mar 2023 06:31:18 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 10:17:57 GMT, Deepa Kumari wrote: >> It was failing as It was using the C++ demangling interface (Demangle) of the old demangler (that is, the C++ API as opposed to the C one). It is not supported by xlclang++ on AIX. >> To demangle names generated by xlclang++ , use cxxabi.h __cxa_demangle interface ( see cxxabi.h). >> >> This Solution applies to the following test >> >> 1. SecondaryErrorTest.java` >> 2. TestSigInfoInHsErrFile.java >> >> >> Reported Issue : [JDK - 8303082](https://bugs.openjdk.org/browse/JDK-8303082) > > Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8303082 : [AIX] Missing C++ name demangling with XLClang++ Hi @TheRealMDoerr , Could you please review this PR? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12742#issuecomment-1489764926 From shade at openjdk.org Thu Mar 30 07:51:18 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Mar 2023 07:51:18 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 21:50:39 GMT, David Holmes wrote: >> The review for [JDK-8304147](https://bugs.openjdk.org/browse/JDK-8304147) pointed out that the top-level HandleMark in dump_for_exit (added to replace the previous coverage from a HandleMarkCleaner in JVM_ENTRY) was not in the right place as no Handles were being used there. Removing that HM and fixing up the ensuing failures led to a set of fixes where HM's were missing at the place of Handle usage. >> >> Testing: tiers 1-4 >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Shipilev feedback - moved HMs back inside the loops. Looks fine to me. (I'd probably put `HandleMark` after the comment, closer to the code in `check_constraints`, but no need to do that if there are no other changes pending.) ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13215#pullrequestreview-1364520564 From dholmes at openjdk.org Thu Mar 30 07:56:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Mar 2023 07:56:21 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 07:48:00 GMT, Aleksey Shipilev wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Shipilev feedback - moved HMs back inside the loops. > > Looks fine to me. (I'd probably put `HandleMark` after the comment, closer to the code in `check_constraints`, but no need to do that if there are no other changes pending.) Thanks @shipilev ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1489855067 From shade at openjdk.org Thu Mar 30 07:56:19 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Mar 2023 07:56:19 GMT Subject: RFR: 8304996: Add missing HandleMarks [v2] In-Reply-To: References: Message-ID: On Wed, 29 Mar 2023 21:37:24 GMT, David Holmes wrote: > Not sure what your issue is with "missing" - the HM's were not present where the Handles were used and hence were missing. Some cases were directly detected by removing the old HM in `dump_for_exit` but I also checked those files for other cases and added them. When I read a synopsis "Add missing HMs", that means to me there are code paths that allocate Handles without HMs -- meaning there is a memory leak. If we just dropped an "umbrella" HM in `dump_for_exit` and only added the HMs that were needed after that removal, that just rebalances the ways we cut and slice the HMs, and that does not affect memory leaks. This distinction is important to gauge how serious the issue is, and whether it should be backported, for example. This is why I wanted to understand the meaning of "missing" here :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13215#issuecomment-1489855066 From mdoerr at openjdk.org Thu Mar 30 10:21:23 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 30 Mar 2023 10:21:23 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 10:17:57 GMT, Deepa Kumari wrote: >> It was failing as It was using the C++ demangling interface (Demangle) of the old demangler (that is, the C++ API as opposed to the C one). It is not supported by xlclang++ on AIX. >> To demangle names generated by xlclang++ , use cxxabi.h __cxa_demangle interface ( see cxxabi.h). >> >> This Solution applies to the following test >> >> 1. SecondaryErrorTest.java` >> 2. TestSigInfoInHsErrFile.java >> >> >> Reported Issue : [JDK - 8303082](https://bugs.openjdk.org/browse/JDK-8303082) > > Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8303082 : [AIX] Missing C++ name demangling with XLClang++ Thanks for implementing it! Looks basically good to me. Please consider my suggestions. src/hotspot/os/aix/porting_aix.cpp line 242: > 240: int status; > 241: char *demangled_name = abi::__cxa_demangle(p_name, nullptr, nullptr, &status); > 242: if ((demangled_name != nullptr) && (status == 0)) { Should the `strncpy` better depend on `status == 0` and the `free` operation on `demangled_name != nullptr`? I'm not sure about the relationship between the two checks. Maybe your version is ok, too. src/hotspot/os/aix/porting_aix.cpp line 246: > 244: p_name[namelen-1] = '\0'; > 245: ALLOW_C_FUNCTION(::free, ::free(demangled_name)); > 246: } I suggest to fix the indentation. ------------- PR Review: https://git.openjdk.org/jdk/pull/12742#pullrequestreview-1364792602 PR Review Comment: https://git.openjdk.org/jdk/pull/12742#discussion_r1153047075 PR Review Comment: https://git.openjdk.org/jdk/pull/12742#discussion_r1153047584 From jcking at openjdk.org Thu Mar 30 14:29:21 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 30 Mar 2023 14:29:21 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 05:36:27 GMT, David Holmes wrote: >> `alignas(PlatformMutex) static PlatformMutex _inflation_locks[inflation_lock_count()];` will not work as the compiler will use default initialization for the array, causing the constructor of PlatformMutex to be called during library loading by the dynamic linker. >> >> With the current `uint8_t` usage, we have to ensure the compiler places the array at a suitable aligned boundary for `PlatformMutex` otherwise its free to place it at `alignas(uint8_t)` AFAIK, which can be 1. > > Ugghh sorry not thinking in C++ - forgot about the implicit initialization in that case. That's okay, so did I originally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13160#discussion_r1153348310 From jcking at openjdk.org Thu Mar 30 14:29:18 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 30 Mar 2023 14:29:18 GMT Subject: RFR: JDK-8304820: Statically allocate ObjectSynchronizer mutexes [v4] In-Reply-To: References: Message-ID: On Tue, 28 Mar 2023 13:29:01 GMT, Justin King wrote: >> Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary align_up > > Signed-off-by: Justin King Last call for complaints/concerns/etc. I'll wait until roughly 24 hours from now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13160#issuecomment-1490404787 From stuefe at openjdk.org Thu Mar 30 14:59:34 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 30 Mar 2023 14:59:34 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 10:17:36 GMT, Martin Doerr wrote: >> Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8303082 : [AIX] Missing C++ name demangling with XLClang++ > > src/hotspot/os/aix/porting_aix.cpp line 242: > >> 240: int status; >> 241: char *demangled_name = abi::__cxa_demangle(p_name, nullptr, nullptr, &status); >> 242: if ((demangled_name != nullptr) && (status == 0)) { > > Should the `strncpy` better depend on `status == 0` and the `free` operation on `demangled_name != nullptr`? I'm not sure about the relationship between the two checks. Maybe your version is ok, too. https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html does not explicitly state an explicit connection between status == 0 and ptr != nullptr. Its at least a bit vague. A bad implementation could allocate the memory and then fail to demangle. So, yes, I'd tie the free to ptr!=NULL only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12742#discussion_r1153392568 From matsaave at openjdk.org Thu Mar 30 16:24:16 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 30 Mar 2023 16:24:16 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v6] In-Reply-To: References: Message-ID: <1FLJWnApnH3KedBESC03L6juksCyYpKvNub2wzsJs1w=.1cf0aeeb-289c-4fe9-af34-4599335c6a7e@github.com> > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Added global assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/c6d7947e..5e48eb99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=04-05 Stats: 32 lines in 13 files changed: 6 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From duke at openjdk.org Thu Mar 30 18:59:24 2023 From: duke at openjdk.org (Deepa Kumari) Date: Thu, 30 Mar 2023 18:59:24 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 10:17:36 GMT, Martin Doerr wrote: >> Deepa Kumari 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 one additional commit since the last revision: >> >> 8303082 : [AIX] Missing C++ name demangling with XLClang++ > > src/hotspot/os/aix/porting_aix.cpp line 242: > >> 240: int status; >> 241: char *demangled_name = abi::__cxa_demangle(p_name, nullptr, nullptr, &status); >> 242: if ((demangled_name != nullptr) && (status == 0)) { > > Should the `strncpy` better depend on `status == 0` and the `free` operation on `demangled_name != nullptr`? I'm not sure about the relationship between the two checks. Maybe your version is ok, too. Thank you so much @TheRealMDoerr and @tstuefe for highlighting this. I will tie the free to ptr!=NULL only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12742#discussion_r1153672262 From cslucas at openjdk.org Thu Mar 30 23:36:20 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 30 Mar 2023 23:36:20 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v5] In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: > Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: > > ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) > > What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: > > ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) > > This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12897/files - new: https://git.openjdk.org/jdk/pull/12897/files/a158ae66..5ef86371 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=03-04 Stats: 552 lines in 18 files changed: 181 ins; 169 del; 202 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897 From dholmes at openjdk.org Fri Mar 31 02:58:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 31 Mar 2023 02:58:18 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v6] In-Reply-To: <1FLJWnApnH3KedBESC03L6juksCyYpKvNub2wzsJs1w=.1cf0aeeb-289c-4fe9-af34-4599335c6a7e@github.com> References: <1FLJWnApnH3KedBESC03L6juksCyYpKvNub2wzsJs1w=.1cf0aeeb-289c-4fe9-af34-4599335c6a7e@github.com> Message-ID: On Thu, 30 Mar 2023 16:24:16 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Added global assert One nit but otherwise thumbs up from me. Thanks for your patience on this one. src/hotspot/share/memory/universe.cpp line 321: > 319: HandleMark hm(THREAD); > 320: > 321: // Explicit null checks are needed if these offsets are larger than the page size Nit: the condition checks smaller, but the comment says larger, which leaves "equal to the page size" unclear leading the reader to wonder "Is the comment wrong or the condition check?". Suggestion: s/larger/not smaller/ ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1366183638 PR Review Comment: https://git.openjdk.org/jdk/pull/13026#discussion_r1153963122 From kevinw at openjdk.org Fri Mar 31 08:54:00 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 31 Mar 2023 08:54:00 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction Message-ID: The Permissions in DCmds relate to remote usage over JMX. "monitor" is generally for reading information, and "control" is generally for making changes. The DCmds for changing compiler directives should have "control" as the required permission. Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. ------------- Commit messages: - 8305237: CompilerDirectives DCmds permissions correction Changes: https://git.openjdk.org/jdk/pull/13262/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13262&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305237 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13262/head:pull/13262 PR: https://git.openjdk.org/jdk/pull/13262 From kevinw at openjdk.org Fri Mar 31 08:54:02 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 31 Mar 2023 08:54:02 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. This has a lot of labels for a trivial change in a very niche feature, but they all seem relevant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1491551796 From duke at openjdk.org Fri Mar 31 09:00:36 2023 From: duke at openjdk.org (Deepa Kumari) Date: Fri, 31 Mar 2023 09:00:36 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v4] In-Reply-To: References: Message-ID: > It was failing as It was using the C++ demangling interface (Demangle) of the old demangler (that is, the C++ API as opposed to the C one). It is not supported by xlclang++ on AIX. > To demangle names generated by xlclang++ , use cxxabi.h __cxa_demangle interface ( see cxxabi.h). > > This Solution applies to the following test > > 1. SecondaryErrorTest.java` > 2. TestSigInfoInHsErrFile.java > > > Reported Issue : [JDK - 8303082](https://bugs.openjdk.org/browse/JDK-8303082) Deepa Kumari has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8303082 : [AIX] Missing C++ name demangling with XLClang++ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12742/files - new: https://git.openjdk.org/jdk/pull/12742/files/49f0267e..1b05a7df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12742&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12742&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12742.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12742/head:pull/12742 PR: https://git.openjdk.org/jdk/pull/12742 From duke at openjdk.org Fri Mar 31 09:00:38 2023 From: duke at openjdk.org (Deepa Kumari) Date: Fri, 31 Mar 2023 09:00:38 GMT Subject: RFR: 8303082 : [AIX] Missing C++ name demangling with XLClang++ [v3] In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 10:18:04 GMT, Martin Doerr wrote: > I suggest to fix the indentation. Fixed Indentation .Thank you @TheRealMDoerr . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12742#discussion_r1154214165 From jcking at openjdk.org Fri Mar 31 14:31:36 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 31 Mar 2023 14:31:36 GMT Subject: Integrated: JDK-8304820: Statically allocate ObjectSynchronizer mutexes In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 15:53:28 GMT, Justin King wrote: > Similar to https://git.openjdk.org/jdk/pull/13143, statically allocate mutexes which live for the lifetime of the process. This pull request has now been integrated. Changeset: fe42312f Author: Justin King URL: https://git.openjdk.org/jdk/commit/fe42312f9b0f8e602b85911307dafb6ddd327bc8 Stats: 17 lines in 1 file changed: 8 ins; 0 del; 9 mod 8304820: Statically allocate ObjectSynchronizer mutexes Reviewed-by: dcubed, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13160 From matsaave at openjdk.org Fri Mar 31 15:14:16 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 31 Mar 2023 15:14:16 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v7] In-Reply-To: References: Message-ID: > In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. > > needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. > the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. > > The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13026/files - new: https://git.openjdk.org/jdk/pull/13026/files/5e48eb99..d62636ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13026&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13026/head:pull/13026 PR: https://git.openjdk.org/jdk/pull/13026 From coleenp at openjdk.org Fri Mar 31 15:27:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Mar 2023 15:27:35 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v7] In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 15:14:16 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Comment fix Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1367153903 From adinn at openjdk.org Fri Mar 31 16:34:18 2023 From: adinn at openjdk.org (Andrew Dinn) Date: Fri, 31 Mar 2023 16:34:18 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v7] In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 15:14:16 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Comment fix Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1367255402 From fparain at openjdk.org Fri Mar 31 17:16:20 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 31 Mar 2023 17:16:20 GMT Subject: RFR: 8241613: Suspicious calls to MacroAssembler::null_check(Register, offset) [v7] In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 15:14:16 GMT, Matias Saavedra Silva wrote: >> In several places in HotSpot, the method MacroAssembler::null_check(Register, offset) is called in a way that never produces any null check in the assembly code. The method null_check(Register, offset) calls needs_explicit_null_check(offset) to determine if it must emit a null check in the assembly code or not. >> >> needs_explicit_null_check(offset) returns true only if the offset is negative or bigger than the os page size. >> the offset being passed is the offset of a field in the header of Java object or a Java array. In both cases, the offset is always positive and smaller than an os page size. A null_check() call with a single parameter will always produce a null check in assembly. >> >> The cases suggested in the issue have been addressed by either removing or preserving the null_check. Verified with tier 1-3 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Comment fix Marked as reviewed by fparain (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13026#pullrequestreview-1367309181 From xliu at openjdk.org Fri Mar 31 17:53:20 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 31 Mar 2023 17:53:20 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v5] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. src/hotspot/share/opto/escape.cpp line 588: > 586: } > 587: > 588: // This method will create a SafePointScalarObjectNode for each combination of you have changed to SafePointScalarMergeNode in code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154745690 From xliu at openjdk.org Fri Mar 31 18:24:18 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 31 Mar 2023 18:24:18 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v5] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. src/hotspot/share/opto/macro.cpp line 632: > 630: safepoints->append_if_missing(sfpt); > 631: } > 632: } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) { I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc. I see that you use it in EA. With ignore_merges, why we also skip EncodeP or MemBarRelease here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154771471 From xliu at openjdk.org Fri Mar 31 18:27:21 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 31 Mar 2023 18:27:21 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v5] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Fri, 31 Mar 2023 18:21:40 GMT, Xin Liu wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. > > src/hotspot/share/opto/macro.cpp line 632: > >> 630: safepoints->append_if_missing(sfpt); >> 631: } >> 632: } else if (ignore_merges && (use->is_Phi() || use->is_EncodeP() || use->Opcode() == Op_MemBarRelease)) { > > I try to understand this part. now `can_eliminate_allocation` can pre-test whether SR can eliminate the alloc. I see that you use it in EA. > > With ignore_merges, why we also skip EncodeP or MemBarRelease here? Do you really need the boolean parameter ignore_merges here? It looks like we can use (safepoints == nullptr) instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154773826 From xliu at openjdk.org Fri Mar 31 18:33:19 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 31 Mar 2023 18:33:19 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v5] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> Message-ID: On Thu, 30 Mar 2023 23:36:20 GMT, Cesar Soares Lucas wrote: >> Can I please get reviews for this PR? >> >> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested. >> >> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png) >> >> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1: >> >> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png) >> >> This PR adds support scalar replacing allocations participating in merges that are used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently. >> >> The approach I used for _rematerialization_ is pretty straightforward. It consists basically in: 1) Extend SafePointScalarObjectNode to represent multiple SR objects; 2) Add a new Class to support rematerialization of SR objects part of merges; 3) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 4) Patch C2 to generate unique types for SR objects participating in some allocation merges. >> >> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straight forward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless. >> >> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also tested with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. src/hotspot/share/opto/escape.cpp line 457: > 455: found_sr_allocate = true; > 456: } else { > 457: ptn->set_scalar_replaceable(false); This member function is const. Do we really need to change ptn's property here? My reading is ophi is profitable as long as we spot any input object which can be eliminated. how about you just return at line 455? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154778280 From xliu at openjdk.org Fri Mar 31 18:41:23 2023 From: xliu at openjdk.org (Xin Liu) Date: Fri, 31 Mar 2023 18:41:23 GMT Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced objects participating in allocation merges [v4] In-Reply-To: References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com> <6NDwZSpjSrokmglncPRp4tM7_Hiq4b26dXukhXODpKo=.8ba7efd0-bc44-4f1e-beb8-c1c68bc33515@github.com> <0UbMqMHtVIayPdJMmfDF6YTadWe4YTlSW6mZc5P3IU8=.c4b1a292-e434-4c57-a5cd-015edca2ec95@github.com> Message-ID: On Fri, 24 Mar 2023 23:37:29 GMT, Vladimir Kozlov wrote: >> I had to make this method static because it uses `value_from_mem` - which I also made static. I had to make `value_from_mem` static so that I can use it outside PhaseMacroExpand. > > I see, you use it in escape.cpp. Okay. I need to review changes there too. or you could construct a temporary PhaseMacroExpand object in EA. I see that you convert many member function to static so you can query in EA. the only blocker is _igvn. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1154785040 From duke at openjdk.org Fri Mar 31 19:38:21 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 31 Mar 2023 19:38:21 GMT Subject: RFR: 8303942: FileMapInfo::write_bytes aborts on a short os::write Message-ID: `os::write` is called in a loop until all the requested size is written. The number of bytes parameter(`size_t nbytes`) is casted to `ssize_t size` to be able to check `> 0` condition. To enable pointer arithmetic, the `const void *` is casted to `const char *` for addition and then recasted back. ### Test local: hotspot:tier1 mach5 tier1-5 ------------- Commit messages: - 8303942: FileMapInfo::write_bytes aborts on a short os::write Changes: https://git.openjdk.org/jdk/pull/13188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303942 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13188/head:pull/13188 PR: https://git.openjdk.org/jdk/pull/13188 From cjplummer at openjdk.org Fri Mar 31 19:44:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 31 Mar 2023 19:44:13 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. I assume this means we have no tests that try to change these compiler directives. Should we? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1492504793 From matsaave at openjdk.org Fri Mar 31 21:20:14 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 31 Mar 2023 21:20:14 GMT Subject: RFR: 8274166: Some CDS tests ignore -Dtest.cds.runtime.options Message-ID: <7FSegNIC7A5_CHchZQhWGAdhDOjqiYE2hrvSb88W1Gg=.3654b6c4-f5fd-448b-b82e-4b8ac06128da@github.com> The test.cds.runtime.options property is used to execute the CDS tests in a special mode. E.g., create the archived with G1 but load the archive with EpsilonGC. Currently tests that are launched with TestCommon.runWithArchive() and CDSTestUtils.runWithArchive() can handle -Dtest.cds.runtime.options. However, some test cases, such as dynamicArchive/HelloDynamic.java, do not call the above two methods, so they ignore -Dtest.cds.runtime.options. The fix is to move the handling of -Dtest.cds.runtime.options to TestCommon.executeAndLog, because most CDS tests use this function to launch a child JVM. Other considerations are necessary now that the option is exposed to other tests, so checks for GC and CDS are necessary. ------------- Commit messages: - Fixed pattern matching - 8274166: Some CDS tests ignore -Dtest.cds.runtime.options Changes: https://git.openjdk.org/jdk/pull/13273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8274166 Stats: 99 lines in 3 files changed: 68 ins; 29 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13273/head:pull/13273 PR: https://git.openjdk.org/jdk/pull/13273